My paper (draft ... since 2007. I actually have some updates, but not enough for publishing) on the subject covers most of the whys and hows:
viewtopic.php?f=34&t=62782&st=0&sk=t&sd=a
Some extra points on the duscussion so far:
- You should really really salt and pepper password hashes. I have a collection of examples where the opposite was a mistake.
- (per-user) salts are usually kept with the other login data (There might be some problems if not so, but of course it's possible to keep them separated, you just have to know what you're doing), so yes, when designing your hashing scheme, assume the attacker has them. I have some ideas of practical implementations, I'll follow up if you want.
- (side-wide) salt (aka pepper) should be looooooong.
- Use hash(hash(pepper.salt.password)) for your hashing scheme.
Kai I haven't read the article carefully (will do so in the near future), but I can easily spot some points of disagreement
1. Double hashing is fine (I know I said otherwise in the 2007 article, I now have solid reasons for using it). (there's a debate about this in another thread)
2. I find no arguments for this "sufficient length" calculation. Salts in my book serve a different purpose, and as such a handful of characters is enough. Arguments, please?
3.
kaisellgren wrote:Rainbow tables are online websites (or even some sort of local databases) that show you a form where you fill the hash and then they give you back the orginal plaintext.
Kai, had I known you wrote such a statement, I would not have entered that discussion with you about hashing. Man, no offense, but if you're mentioning something in a
security article at least read the bloody wikipedia article, okay? (Well actually in my book if you have to read the wp article, it's too early to write anything on the subject)
4. Also, citing your sources would be nice. I think my article (above) should be among them.