starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Storing and retrieving secrets in hashed/encrypted format #921

New Issue
Closed
opened 2025-12-29 16:26:59 +01:00 by adam · 3 comments
adam commented 2025-12-29 16:26:59 +01:00
Owner
Copy Link

Originally created by @lampwins on GitHub (May 8, 2017).

Issue type: feature request

I am using netbox as a source of truth from which I build device configurations. I need an easy way to retrieve hashed secrets that would go in those configurations.

The current secret storage/retrieval methodology works great for securely storing and retrieving plain text secrets. However, it is cumbersome in a programatic approach. Furthermore, in the end I do not want a plain text password (most of the time), I want a hashed/encrypted version to go into my device configuration.

What I propose is the ability to store hashed/encrypted versions (user provided so the secret is hashed/encrypted for its entire lifecycle) of the secrets along side the plain text version. The difference is that the hashed/encrypted version can be retrieved without the intermediary session key because they are not encrypted with the PKI currently in place for plain text secrets.

So I am not asking for a replacement of the current means, just a simpler way to store and retrieved hashed/encrypted secrets.

Should note this targets v2 in reference to the intermediary session keys.

Originally created by @lampwins on GitHub (May 8, 2017). ### Issue type: feature request I am using netbox as a source of truth from which I build device configurations. I need an easy way to retrieve hashed secrets that would go in those configurations. The current secret storage/retrieval methodology works great for securely storing and retrieving plain text secrets. However, it is cumbersome in a programatic approach. Furthermore, in the end I do not want a plain text password (most of the time), I want a hashed/encrypted version to go into my device configuration. What I propose is the ability to store hashed/encrypted versions (user provided so the secret is hashed/encrypted for its entire lifecycle) of the secrets along side the plain text version. The difference is that the hashed/encrypted version can be retrieved without the intermediary session key because they are not encrypted with the PKI currently in place for plain text secrets. So I am not asking for a replacement of the current means, just a simpler way to store and retrieved hashed/encrypted secrets. Should note this targets v2 in reference to the intermediary session keys.
adam closed this issue 2025-12-29 16:26:59 +01:00
adam commented 2025-12-29 16:26:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 9, 2017):

The current secret storage/retrieval methodology works great for securely storing and retrieving plain text secrets. However, it is cumbersome in a programatic approach.

I can retrieve the plaintexts for a list of devices by sending a single API call with a session key. Can't get much simpler than that unless you store the plaintexts in the database.

Furthermore, in the end I do not want a plain text password (most of the time), I want a hashed/encrypted version to go into my device configuration.

Best practice is to provide the device the plaintext value and let it derive the hash. This is because hashing logic may change in future software releases (e.g. IOS type 7 versus salted MD5).

The difference is that the hashed/encrypted version can be retrieved without the intermediary session key because they are not encrypted with the PKI currently in place for plain text secrets.

So you're essentially just storing an arbitrary piece of config data, no different from a domain name or NTP server. I don't believe NetBox is the place for this. Why not keep it with everything else you use to populate your configuration templates?

@jeremystretch commented on GitHub (May 9, 2017): > The current secret storage/retrieval methodology works great for securely storing and retrieving plain text secrets. However, it is cumbersome in a programatic approach. I can retrieve the plaintexts for a list of devices by sending a single API call with a session key. Can't get much simpler than that unless you store the plaintexts in the database. > Furthermore, in the end I do not want a plain text password (most of the time), I want a hashed/encrypted version to go into my device configuration. Best practice is to provide the device the plaintext value and let it derive the hash. This is because hashing logic may change in future software releases (e.g. IOS type 7 versus salted MD5). > The difference is that the hashed/encrypted version can be retrieved without the intermediary session key because they are not encrypted with the PKI currently in place for plain text secrets. So you're essentially just storing an arbitrary piece of config data, no different from a domain name or NTP server. I don't believe NetBox is the place for this. Why not keep it with everything else you use to populate your configuration templates?
adam commented 2025-12-29 16:26:59 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (May 9, 2017):

I can retrieve the plaintexts for a list of devices by sending a single API call with a session key. Can't get much simpler than that unless you store the plaintexts in the database.

Agreed that once a session key is obtained, this is very simple. The cumbersome part however is getting the session key, as the client has to have access to the user's private key. In my example, I am talking about a blackbox client that only allows basic webhook calls to be defined. In such a case, the API token is the only feasible means of authentication that can be configured in the client. A two step process is simply not possible.

Best practice is to provide the device the plaintext value and let it derive the hash. This is because hashing logic may change in future software releases (e.g. IOS type 7 versus salted MD5).

I am not so sure I agree with that. I can't speak for Cisco, but other systems like Juniper use Unix formatted hashes which are self descriptive as to what algorithm/salt/etc are used. So that is much less of an issue between versions. Even Juniper's crypto changes in 15.1 remain fully backwards compatible because of this. Also once rendered, my configs reside in a git repo. Many people do this, so you can't tell me that having plain text passwords sitting at rest is a best practice here. Granted that is somewhat unrelated and we are getting into the weeds with that anyway.

So you're essentially just storing an arbitrary piece of config data, no different from a domain name or NTP server. I don't believe NetBox is the place for this. Why not keep it with everything else you use to populate your configuration templates?

Yeah you probably have me here. However, to me it makes sense to have these stored with their plaintext counterparts. Perhaps there is a solution here to generate the hash (for known types) when the plain text is updated.

@lampwins commented on GitHub (May 9, 2017): > I can retrieve the plaintexts for a list of devices by sending a single API call with a session key. Can't get much simpler than that unless you store the plaintexts in the database. Agreed that once a session key is obtained, this is very simple. The cumbersome part however is getting the session key, as the client has to have access to the user's private key. In my example, I am talking about a blackbox client that only allows basic webhook calls to be defined. In such a case, the API token is the only feasible means of authentication that can be configured in the client. A two step process is simply not possible. > Best practice is to provide the device the plaintext value and let it derive the hash. This is because hashing logic may change in future software releases (e.g. IOS type 7 versus salted MD5). I am not so sure I agree with that. I can't speak for Cisco, but other systems like Juniper use Unix formatted hashes which are self descriptive as to what algorithm/salt/etc are used. So that is much less of an issue between versions. Even Juniper's crypto changes in 15.1 remain fully backwards compatible because of this. Also once rendered, my configs reside in a git repo. Many people do this, so you can't tell me that having plain text passwords sitting at rest is a best practice here. Granted that is somewhat unrelated and we are getting into the weeds with that anyway. > So you're essentially just storing an arbitrary piece of config data, no different from a domain name or NTP server. I don't believe NetBox is the place for this. Why not keep it with everything else you use to populate your configuration templates? Yeah you probably have me here. However, to me it makes sense to have these stored with their plaintext counterparts. Perhaps there is a solution here to generate the hash (for known types) when the plain text is updated.
adam commented 2025-12-29 16:27:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 12, 2017):

After thinking about this for a bit, I want to restrict the secrets app in NetBox to handling only encrypted data. It's already a fairly complex thing without introducing "our hash versus their hash" sort of nuances. Anything that doesn't need to be encrypted/decrypted can be kept in a general purpose key-value store. (Whether or not it makes sense to extend NetBox to include such a function is another discussion.)

@jeremystretch commented on GitHub (May 12, 2017): After thinking about this for a bit, I want to restrict the secrets app in NetBox to handling only encrypted data. It's already a fairly complex thing without introducing "our hash versus their hash" sort of nuances. Anything that doesn't need to be encrypted/decrypted can be kept in a general purpose key-value store. (Whether or not it makes sense to extend NetBox to include such a function is another discussion.)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#921
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?