New answers tagged

4

Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem. Additionally, since you have control over the ...


3

You can use bCrypt. The simple solution is sending your user a an Id and the Token: https://example.com/pwdReset?resetId=123&resetKey=[your long randomly generated key] You can lookup the hash using the id (just like you would use the username to lookup the user's password hash).


3

I want to make a few points in addition to @NeilSmithline's excellent answer. Taking a 256-bit random value and hashing it with SHA-256, the output will still have (roughly) 256 bits of entropy. I say "roughly" because it's an open problem whether SHA256 actually maps to every possible string on 256 bits - but for all practical purposes, it's close enough. ...


4

Yes. Salt is used to prevent precomputation attacks, but random 256 bit strings are too large for precomputation. Slow hash functions with many iterations are meant to slow down dictionary attacks, but random 256 bit strings are too big for a dictionary or for exhaustive testing. So a single SHA256 hash is secure for long, cryptographically secure random ...



Top 50 recent answers are included