Colin will probably agree with me: people who build authentication systems don't spend a lot of time thinking about salts.
I agree, in the sense that people don't spend a lot of time thinking about breathing. We just do it. Grab 256 bits from /dev/random (or from your internal entropy pool, if you have one) and stick a salt or nonce onto password you hash and every protocol packet you send.
Of course, most of them wouldn't waste their time redesigning a password storage system; they'd use Mazieres/Provos "bcrypt" and be done with it.
For a straight-forward "users logging into a website", absolutely. But most people who design authentication systems have more stringent requirements, like "allow users to authenticate themselves in such a way that a bogus server can't steal their credentials", at which point things get a bit more interesting. :-)
It would be great if we could just give a consistent, clear recommendation for people to use bcrypt here. You're a BSD person, I assume you like Mazieres and Niels as much as I do.
MD5(MD5(MD5(etc))) is still pretty silly. Why hack? Do it right.
MD5(MD5(MD5(etc))) is still pretty silly. Why hack? Do it right.
I wasn't suggesting that people should use iterated MD5 has a password hash. I was giving it as an example of how a password hash can be made more brute-force-resistant by doing extra work.
It would be great if we could just give a consistent, clear recommendation for people to use bcrypt here.
I'm not arguing with that. Hey everybody, do what Thomas says and use bcrypt!
But -- maybe due to my background in academia -- I think it's really important for people to understand why the authentication schemes they keep on inventing are bad. You're doing a good job of jumping in and telling everybody to use bcrypt -- so I'm taking care of explaining the cryptography so that people will understand what they're doing wrong and what bcrypt does right.
You're also stronger on crypto than I am. The background is neat, but we probably don't want to fall into the trap that Schneier did, documenting a lot of trivia and failing to provide clear explanations, so that we wind up with applications that use CAST and Interlock instead of TLS. =)
Comments
Colin will probably agree with me: people who build authentication systems don't spend a lot of time thinking about salts.
I agree, in the sense that people don't spend a lot of time thinking about breathing. We just do it. Grab 256 bits from /dev/random (or from your internal entropy pool, if you have one) and stick a salt or nonce onto password you hash and every protocol packet you send.
Of course, most of them wouldn't waste their time redesigning a password storage system; they'd use Mazieres/Provos "bcrypt" and be done with it.
For a straight-forward "users logging into a website", absolutely. But most people who design authentication systems have more stringent requirements, like "allow users to authenticate themselves in such a way that a bogus server can't steal their credentials", at which point things get a bit more interesting. :-)
It would be great if we could just give a consistent, clear recommendation for people to use bcrypt here. You're a BSD person, I assume you like Mazieres and Niels as much as I do. MD5(MD5(MD5(etc))) is still pretty silly. Why hack? Do it right.
MD5(MD5(MD5(etc))) is still pretty silly. Why hack? Do it right.
I wasn't suggesting that people should use iterated MD5 has a password hash. I was giving it as an example of how a password hash can be made more brute-force-resistant by doing extra work.
It would be great if we could just give a consistent, clear recommendation for people to use bcrypt here.
I'm not arguing with that. Hey everybody, do what Thomas says and use bcrypt!
But -- maybe due to my background in academia -- I think it's really important for people to understand why the authentication schemes they keep on inventing are bad. You're doing a good job of jumping in and telling everybody to use bcrypt -- so I'm taking care of explaining the cryptography so that people will understand what they're doing wrong and what bcrypt does right.
You're also stronger on crypto than I am. The background is neat, but we probably don't want to fall into the trap that Schneier did, documenting a lot of trivia and failing to provide clear explanations, so that we wind up with applications that use CAST and Interlock instead of TLS. =)