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

User tokens are stored in plaintext #11501

New Issue
Closed
opened 2025-12-29 21:46:03 +01:00 by adam · 7 comments
adam commented 2025-12-29 21:46:03 +01:00
Owner
Copy Link

Originally created by @sepetuks on GitHub (Aug 19, 2025).

NetBox version

v4.3.3

Feature type

Change to existing functionality

Proposed functionality

Keep users tokens hashed in database

Use case

When user creates token for api or any other access this token is stored in plaintext in DB table "users_token"
So anyone who has access to DB can take token and impersonate as other user.

example: DB administrator can gain access to application as different user.

Database changes

key field in DB table "users_token" should be hashed.

External dependencies

No response

Originally created by @sepetuks on GitHub (Aug 19, 2025). ### NetBox version v4.3.3 ### Feature type Change to existing functionality ### Proposed functionality Keep users tokens hashed in database ### Use case When user creates token for api or any other access this token is stored in plaintext in DB table "users_token" So anyone who has access to DB can take token and impersonate as other user. example: DB administrator can gain access to application as different user. ### Database changes key field in DB table "users_token" should be hashed. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:46:03 +01:00
adam closed this issue 2025-12-29 21:46:03 +01:00
adam commented 2025-12-29 21:46:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 19, 2025):

Keep users tokens hashed in database

If all the tokens are hashed, how does the application authenticate a given token? There is no username or other identifier to indicate the specific record against which the given token should be validated, and attempting to validate it against every hash would be poor practice (not to mention highly inefficient).

I'm not opposed to the change in general (the ALLOW_TOKEN_RETRIEVAL configuration parameter was introduced back in NetBox v3.4 as a step toward this eventuality), but the implementation needs further consideration. There are certainly options to achieve this, but implementing this in a way that does not break the current token structure (assuming we want to keep it) might be tricky.

@jeremystretch commented on GitHub (Aug 19, 2025): > Keep users tokens hashed in database If all the tokens are hashed, how does the application authenticate a given token? There is no username or other identifier to indicate the specific record against which the given token should be validated, and attempting to validate it against _every_ hash would be poor practice (not to mention highly inefficient). I'm not opposed to the change in general (the [`ALLOW_TOKEN_RETRIEVAL`](https://netboxlabs.com/docs/netbox/configuration/security/#allow_token_retrieval) configuration parameter was introduced back in NetBox v3.4 as a step toward this eventuality), but the implementation needs further consideration. There are certainly options to achieve this, but implementing this in a way that does not break the current token structure (assuming we want to keep it) might be tricky.
adam commented 2025-12-29 21:46:04 +01:00
Author
Owner
Copy Link

@sepetuks commented on GitHub (Aug 19, 2025):

Keep users tokens hashed in database

If all the tokens are hashed, how does the application authenticate a given token? There is no username or other identifier to indicate the specific record against which the given token should be validated, and attempting to validate it against every hash would be poor practice (not to mention highly inefficient).

sorry could not withhold answering with question: why then user passwords are not stored in plaintext?

@sepetuks commented on GitHub (Aug 19, 2025): > > Keep users tokens hashed in database > > If all the tokens are hashed, how does the application authenticate a given token? There is no username or other identifier to indicate the specific record against which the given token should be validated, and attempting to validate it against _every_ hash would be poor practice (not to mention highly inefficient). sorry could not withhold answering with question: why then user passwords are not stored in plaintext?
adam commented 2025-12-29 21:46:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 19, 2025):

why then user passwords are not stored in plaintext?

The plaintext username functions as the identifier for the hash against which the provided password is validated. As I mentioned, there is no such complementary identifier when using a bearer token.

@jeremystretch commented on GitHub (Aug 19, 2025): > why then user passwords are not stored in plaintext? The plaintext username functions as the identifier for the hash against which the provided password is validated. As I mentioned, there is no such complementary identifier when using a bearer token.
adam commented 2025-12-29 21:46:05 +01:00
Author
Owner
Copy Link

@sepetuks commented on GitHub (Aug 20, 2025):

Why at least just not hash token and compare hashed values?

@sepetuks commented on GitHub (Aug 20, 2025): Why at least just not hash token and compare hashed values?
adam commented 2025-12-29 21:46:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 20, 2025):

I suggest you research conventional salted hash implementations; the problem will present itself quickly. Django's own password hashing implementation serves as a great reference.

@jeremystretch commented on GitHub (Aug 20, 2025): I suggest you research conventional salted hash implementations; the problem will present itself quickly. Django's own [password hashing implementation](https://docs.djangoproject.com/en/5.2/topics/auth/passwords/) serves as a great reference.
adam commented 2025-12-29 21:46:05 +01:00
Author
Owner
Copy Link

@mr1716 commented on GitHub (Aug 22, 2025):

2 questions for someone who’s curious:

  1. The documentation provides a default API value. Should that be changed or modified in some way? (Ie if not changed, then the attacker already has admin api access)
  2. if the user is able to access the tokens in plaintext, what else would they have access to? (Ie would there be other things they may do that would be issues as well)
@mr1716 commented on GitHub (Aug 22, 2025): 2 questions for someone who’s curious: 1) The documentation provides a default API value. Should that be changed or modified in some way? (Ie if not changed, then the attacker already has admin api access) 2) if the user is able to access the tokens in plaintext, what else would they have access to? (Ie would there be other things they may do that would be issues as well)
adam commented 2025-12-29 21:46:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 29, 2025):

After some research into current best practices, I've submitted FR #20210 detailing a proposed implementation for a new format of API authentication token, which will support secure storage in the database.

I'm going to close this FR as its primary concern is addressed by #20210.

@jeremystretch commented on GitHub (Aug 29, 2025): After some research into current best practices, I've submitted FR #20210 detailing a proposed implementation for a new format of API authentication token, which will support secure storage in the database. I'm going to close this FR as its primary concern is addressed by #20210.
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 type: feature
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#11501
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?