On Aug 30, 2010, at 10:29 PM, Ralf Eggert wrote:
interesting stuff. But where should the distinct salt per user be
saved?
It feels quite wrong to store it in the database right beside the
password. Or should it be combined from, lets say: user id, email
address and registration date?
Ideally the salt should be more strongly pseudorandom. You don't need
to use any constant or other user-related field in the calculation of
the salt. Just make it as random as you can make it. And make sure
you use a distinct random salt per user.
If the attacker gains access to make queries against your database,
you've lost the game anyway, so storing the salt in a column named
"salt" in the same table with the hashed password is not significantly
riskier than storing the salt anywhere else that the attacker gains
access to.
In other words, don't rely on security by obscurity. Don't even favor
security by obscurity. In some ways, I think it's better *not* to
make your code or database obscure at all, if that encourages you to
strengthen more effective security measures to prevent attackers from
gaining access.
Regards,
Bill Karwin
