#16 Secure Tokens

Open
opened 4 years ago by spaghetti · 0 comments

This applies to both session tokens and password reset tokens (and possibly more).

Currently, we just store a token and give the user the same token either via a cookie or through email. Anyone with this token can masquerade as the user for the purpose of whatever the token was generated for.

A storage scheme is available where we do not need to actually store the complete token ourselves to authenticate them, leaving one less source of token leakage. Instead, we should:

  • Store one half of the token normally
  • Store a hash of the other half of the token

This way we can still verify users by the token they have, but if we leak the franken-token-hash accidentally, nobody can use it to masquerade as the user.

This applies to both session tokens and password reset tokens (and possibly more). Currently, we just store a token and give the user the same token either via a cookie or through email. Anyone with this token can masquerade as the user for the purpose of whatever the token was generated for. A storage scheme is available where we do not need to actually store the complete token ourselves to authenticate them, leaving one less source of token leakage. Instead, we should: * Store one half of the token normally * Store a hash of the other half of the token This way we can still verify users by the token they have, but if we leak the franken-token-hash accidentally, nobody can use it to masquerade as the user.
spaghetti added the
Security
label 4 years ago
spaghetti added the
Migrated Issue
label 4 years ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.