Can anyone take a stab at explaining the fetish webdevs have for password salt schemes? I don't get it. Colin will probably agree with me: people who build authentication systems don't spend a lot of time thinking about salts. 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.
If an article like this makes even a couple of neurons in your head light up, you have better things to do than reinvent the password storage wheel. Use somebody else's good system. This is almost security 101.
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. =)
Probably because salting is one of the easier crypto ideas to grok and one of the safer ones to get wrong? Salting is just a constant factor optimization (assuming password length is bounded and short). It's designed to remove the opportunity to do a dictionary lookup and force the attacker to actually compute the password hash. But it doesn't change the algorithmic time of the attack at all. So it's "safe" to pontificate about.
At worst, you're going to make an attack available only to a person with a botted cluster of machines accessible to a single guy with a laptop. Meh.
Comments
Can anyone take a stab at explaining the fetish webdevs have for password salt schemes? I don't get it. Colin will probably agree with me: people who build authentication systems don't spend a lot of time thinking about salts. 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.
If an article like this makes even a couple of neurons in your head light up, you have better things to do than reinvent the password storage wheel. Use somebody else's good system. This is almost security 101.
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. =)
Probably because salting is one of the easier crypto ideas to grok and one of the safer ones to get wrong? Salting is just a constant factor optimization (assuming password length is bounded and short). It's designed to remove the opportunity to do a dictionary lookup and force the attacker to actually compute the password hash. But it doesn't change the algorithmic time of the attack at all. So it's "safe" to pontificate about.
At worst, you're going to make an attack available only to a person with a botted cluster of machines accessible to a single guy with a laptop. Meh.
For all you ruby/rails nuts out there, ruby already has a good gem that makes using bcrypt easy:
http://bcrypt-ruby.rubyforge.org/
It even handles the salting for you, so you don't have to think about it.