4 ms·

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

by runn1ng 17y ago

kelnos 17y ago
Presumably, bcrypt is something that has been vetted by crypto experts, whereas your idea is just some random thing you thought up. Maybe you personally are a crypto expert and know for a fact that your plan will work, but the vast majority of people aren't. A packaged solution like bcrypt that doesn't give the developer enough rope to hang themselves (and their users) is a much better idea. The idea is a developer will just do: passwd_str = bcrypt_string_from_password(passwd); db_store_password(userid, passwd_str); and just be done with it, rather than having to decide between ROT13 (kidding), hashing, salted hashing, HMAC, etc. A couple years ago I thought applying SHA1 to a password before storing it in the DB was perfectly fine. Later I discovered that it was better to use a salt. More recently I've discovered that both of those approaches are flawed. Fortunately I've never written a large-scale application that deals with storing passwords, but I'm sure there are many application developers like me who would write much safer password storage routines if they didn't have to be the one to select an algorithm. Now, I'm not saying bcrypt is the answer (I know nothing about it beyond what I've read on HN), but that's the general problem with your hypothetical proposal.
- ErrantX 17y ago
  whereas your idea is just some random thing you thought up He might also have got the idea from one of tptacek's suggestions not long ago. The difference between doing the iterations and bcrypt is.. well.. not massive in a practical sense. You could do either (if your already MD5'ing passwords once [hmmmm], for example, then it is a quicker solution)
  - tptacek 17y ago
    There's a difference: bcrypt (and moreso scrypt) were designed to be hard to speed up, while SHA1 was designed at least in part to be easy to speed up. But in practical terms, "stretched" SHA1 is fine. I won't bitch at anyone for using it.
dfranke 17y ago
Nothing enormous; that's basically what PBKDF1 does. cperciva might correct me on this, but IIRC there are some minor concerns, addressed by PBKDF2, which is a slightly more complicated construction, about the iterated hash function degenerating into cycles. I don't think there have ever been any practical results exploiting this. PBKDF2 is just as good a choice as bcrypt, and a better-supported one.
- cperciva 17y ago
  100% correct until the last sentence. :-) PBKDF2 is just as good a choice as bcrypt bcrypt has a slight advantage over PBKDF2 in that it requires a larger ASIC area. It's only a constant factor better than PBKDF2, but making an attack 5x more expensive is still somewhat useful.

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

by runn1ng 17y ago

What is the difference, then, between using bcrypt and iterating MD5 10^6 times?

Presumably, bcrypt is something that has been vetted by crypto experts, whereas your idea is just some random thing you thought up. Maybe you personally are a crypto expert and know for a fact that your plan will work, but the vast majority of people aren't. A packaged solution like bcrypt that doesn't give the developer enough rope to hang themselves (and their users) is a much better idea. The idea is a developer will just do: passwd_str = bcrypt_string_from_password(passwd); db_store_password(userid, passwd_str); and just be done with it, rather than having to decide between ROT13 (kidding), hashing, salted hashing, HMAC, etc. A couple years ago I thought applying SHA1 to a password before storing it in the DB was perfectly fine. Later I discovered that it was better to use a salt. More recently I've discovered that both of those approaches are flawed. Fortunately I've never written a large-scale application that deals with storing passwords, but I'm sure there are many application developers like me who would write much safer password storage routines if they didn't have to be the one to select an algorithm. Now, I'm not saying bcrypt is the answer (I know nothing about it beyond what I've read on HN), but that's the general problem with your hypothetical proposal.

ErrantX 17y ago
whereas your idea is just some random thing you thought up He might also have got the idea from one of tptacek's suggestions not long ago. The difference between doing the iterations and bcrypt is.. well.. not massive in a practical sense. You could do either (if your already MD5'ing passwords once [hmmmm], for example, then it is a quicker solution)
- tptacek 17y ago
  There's a difference: bcrypt (and moreso scrypt) were designed to be hard to speed up, while SHA1 was designed at least in part to be easy to speed up. But in practical terms, "stretched" SHA1 is fine. I won't bitch at anyone for using it.

dfranke 17y ago

Nothing enormous; that's basically what PBKDF1 does. cperciva might correct me on this, but IIRC there are some minor concerns, addressed by PBKDF2, which is a slightly more complicated construction, about the iterated hash function degenerating into cycles. I don't think there have ever been any practical results exploiting this. PBKDF2 is just as good a choice as bcrypt, and a better-supported one.

cperciva 17y ago
100% correct until the last sentence. :-) PBKDF2 is just as good a choice as bcrypt bcrypt has a slight advantage over PBKDF2 in that it requires a larger ASIC area. It's only a constant factor better than PBKDF2, but making an attack 5x more expensive is still somewhat useful.