Any salt at all will obviously help when salting and hashing a user's password. Are there any best practices for how long the salt should be? I'll be storing the salt in my user table, so I would like the best tradeoff between storage size and security. Is a random 10 character salt enough? Or do I need something longer?
A:
I don't know if there's an industry standard, but I would recommend at least 10 characters of which a few are strange symbols (and I mean extra strange, like ¤, ©, or ¦)
EDIT: I understand the arguments for embedding in the code vs storing in the database. Embed it in the code and you can't find it if you steal the database. BUT, the problem with embedding the salt in the code, is that you're able to produce a rainbow table for the entire user database if you steal the code. I would probably go for both.
Tom Ritter
2008-10-08 18:25:32
Please don't ever think of it in terms of characters. Hashing algorithms don't. Just generate a completely random set of bits. If you have a 256-bit salt, generate 256 random bits. Done.
Stephen Touset
2009-09-09 15:28:55
There is zero reason to hardcode a salt in code. Its value is not in its secrecy, so salts being stolen along with a database is of no concern whatsoever. You could publish a list of your salts and it would make no effective difference.
Stephen Touset
2010-07-29 16:12:22
+8
A:
Currently accepted standards for hashing passwords create a new 16 character long salt for every passwort and store the salt with the password hash.
Of course proper cryptographic care to create really random salt should be taken.
David Schmitt
2008-10-08 18:33:35
+8
A:
I don't have a recommendation about the length of the salt, but the answers that are showing up here have a lot of bad information. Your salt should definitely:
- be random
- be per secret (not a single value stored in your program image or configuration file).
The salt is not a cryptographic secret, so storing it in your table is no problem. The only purpose of a salt is to ensure that when different instances of the same item are hashed (or encrypted) that you get a different result.
Michael Burr
2008-10-08 18:44:43
+1
A:
For those who don't know what salt is: Salt (cryptography) on Wikipedia
David
2008-10-08 18:49:03
+3
A:
Honestly, there's no defensible reason not to have the salt be the same exact length as the hashed password. If you're using SHA-256, then you have a 256-bit hash. There's no reason not to use a 256-bit salt.
More than 256 bits won't net you any improvement in security, mathematically. But going with a shorter salt may always end up with a situation where a rainbow table catches up to your salt length -- especially with shorter salts.
Stephen Touset
2009-09-08 18:49:17