Skip to content

Hash Tokens in User Records #253

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
spjmurray opened this issue May 6, 2025 · 0 comments · May be fixed by #254
Open

Hash Tokens in User Records #253

spjmurray opened this issue May 6, 2025 · 0 comments · May be fixed by #254
Assignees
@spjmurray
Labels
security Here be CVEs, GHSAs etc.

Comments

@spjmurray
Copy link
Contributor

While keeping active tokens in the User record is great for a quick and easy way to compare what is handed over at the API, it's also a honey pot of information. Refesh tokens are bound to the client ID, and issuing a token needs the client secret, which is another problem in itself! So really the only thing to worry about here is access tokens that are alive for an hour, or service account tokens which is slightly more of an issue being live for up to 3 months.

So basically run these through SHA2. For a transparent upgrade, we can probably prefix the entry with SHA2-512:<hash> to identify the algorithm, defaulting to plaintext for backwards compatibility. We can even extend this to SHA2-512:512:<hash> to identify the number of rounds to subject the hash to for improved security, and also allow us to increase the number of rounds in the future to thwart crypanalysis.
@spjmurray spjmurray self-assigned this May 6, 2025
@spjmurray spjmurray added the security Here be CVEs, GHSAs etc. label May 6, 2025
spjmurray added a commit that referenced this issue May 7, 2025
@spjmurray
Add Token Hashing
460e329 
Reduces the attack surface by obfuscating tokens using SHA256 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
@spjmurray spjmurray linked a pull request May 7, 2025 that will close this issue
Open
spjmurray added a commit that referenced this issue May 7, 2025
@spjmurray
Add Token Hashing
22e9872 
Reduces the attack surface by obfuscating tokens using SHA512 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
spjmurray added a commit that referenced this issue May 8, 2025
@spjmurray
Add Token Hashing
b14fcae 
Reduces the attack surface by obfuscating tokens using SHA512 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
spjmurray added a commit that referenced this issue May 14, 2025
@spjmurray
Add Token Hashing
a517524 
Reduces the attack surface by obfuscating tokens using SHA512 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
spjmurray added a commit that referenced this issue May 16, 2025
@spjmurray
Add Token Hashing
f75b69a 
Reduces the attack surface by obfuscating tokens using SHA512 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
spjmurray added a commit that referenced this issue May 22, 2025
@spjmurray
Add Token Hashing
225afe9 
Reduces the attack surface by obfuscating tokens using SHA512 and
PBKDF2, thus they are only ever persisted client side, we continue to
maintain a plaintext in-memory cache for performace reasons.

Fixes #253
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spjmurray spjmurray

Labels
security Here be CVEs, GHSAs etc.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add Token Hashing nscaledev/uni-identity
1 participant
@spjmurray