5 ms·
A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating serv
by duncanj 17y ago
A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem.
For some reason, it just doesn't seem useful to me to store the salt with the user's record, if you're worried about someone with a rainbow crack running through your password file.
Edit: that last paragraph was stupid.
- ryanwaggoner 17y agoYou lost me...the way I've always seen salts used is just before hashing, but the same salt is used for all the passwords. Then when authenticating passwords, you salt & hash the incoming password and compare to the stored record in the DB. Am I doing it wrong?
- jonknee 17y agoUsing the same salt for all records makes it significantly easier for someone to crack your whole DB. A different salt for each row means they'd have to go through the effort of creating a rainbow table for each row instead of a whole database.
- deleted 17y ago[deleted]
- cperciva 17y agoA long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem. This is called "key strengthening" and was proposed by Abadi et al. in 1997. It works, but it's not as secure as key stretching using a well designed key derivation function.