5 ms·

Better still, use scrypt. HN's very own @cperciva wrote it. http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html It requires a lot more memor

Better still, use scrypt. HN's very own @cperciva wrote it. http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html It requires a lot more memory to brute-force it, thereby defeating any speed gains from parallelism.

raverbashing 14y ago
THANK YOU "use bcrypt" has become an HN meme, with all the bad implications of it As if scrypt, pbkdf2 didn't exist. Or as if bcrypt has always existed and doesn't have any weakness
- carbocation 14y ago
  If a database of bcrypted passwords from LNKD had been leaked, we'd be having a totally different conversation right now. (Same, of course, with scrypt etc.)
  - raverbashing 14y ago
    Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first
    - toyg 14y ago
      These hashes were posted on a forum as a plea for help: the guy did not have enough computational power to crack them all on his own. Had they been salted bcrypt hashes, it might have actually discouraged him to the point of not even trying. So yeah, the weakest passwords will always fall, but good solutions will go to great length to protect even the most clueless of users.
    - carbocation 14y ago
      Am not a cryptographer by any means, so please correct me if I'm wrong: If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuously, you could expect to recover one 6-char every day if the passwords were randomly distributed in the 6-char alphanumeric space. So, pretty feasible, assuming a 100ms cost. Short passwords do hurt you; I agree. Now for 8-char alphanumeric passwords, you'd have to run ~1 million CPUs continuously to expect to recover one per day at a 100ms-per-pop cost. This is more of a stretch, assuming you're trying to do this with, e.g., botnets. It seems that someone asking for help cracking a password list on a forum would probably not be able to assemble this much computing power. Or 1 billion CPUs continuously to expect to recover one 10-char alphanumeric password per day. Of course, the assumption of random alphanumerics is wrong, both because many people will use common passwords and because others will use non-alphanumeric character substitution. At any rate, it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario, short of plaintext passwords.
      - tptacek 14y ago
        You are not wrong at all.
      - raverbashing 14y ago
        I didn't do the math but it sounds right. But suppose tomorrow it takes 10ms. Also, tomorrow, available spaces will increase, so the likelihood of a space vs time tradeoff (even partial) increases WEP was considered "good enough" at first (even though it had obvious problems at first like key size), WAP was considered unbreakable at first, today it's feasible with cloud computing or GPUs. And then we'll be complaining on HN that they didn't use xyzcrypt or something instead of bcrypt. " it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario" Yes. Salt is password storage 101!
        pjscott 14y ago
- tptacek 14y ago
  Please stop stirring up drama about this issue. While you are technically incorrect (PBKDF2-SHA1 is faster than and thus inferior to bcrypt), it's irrelevant: all three of [scrypt, bcrypt, PBKDF2] are just fine, and you can safely pick one at random.
- darkarmani 14y ago
  What weakness does bcrypt have?
jere 14y ago
The reason people are going to use bcrypt is that there are more likely going to be bcrypt implementations in their given language: http://stackoverflow.com/questions/10149554/are-there-any-php-implementations-of-scrypt http://stackoverflow.com/questions/10149554/are-there-any-ph... I just had to make this choice a few days ago and bcrypt seemed like the best option with working PHP implementations. And I sure as hell am not going to try to roll my own.
- jakejake 14y ago
  The responses to that stack overflow question makes me want to punch somebody in the face! The #1 google response for info about Scrypt for php now points to an article arguing about the semantics of the question with no answer. Classic!

raverbashing 14y ago

THANK YOU "use bcrypt" has become an HN meme, with all the bad implications of it As if scrypt, pbkdf2 didn't exist. Or as if bcrypt has always existed and doesn't have any weakness

carbocation 14y ago
If a database of bcrypted passwords from LNKD had been leaked, we'd be having a totally different conversation right now. (Same, of course, with scrypt etc.)
- raverbashing 14y ago
  Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first
  - toyg 14y ago
    These hashes were posted on a forum as a plea for help: the guy did not have enough computational power to crack them all on his own. Had they been salted bcrypt hashes, it might have actually discouraged him to the point of not even trying. So yeah, the weakest passwords will always fall, but good solutions will go to great length to protect even the most clueless of users.
  - carbocation 14y ago
    Am not a cryptographer by any means, so please correct me if I'm wrong: If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuously, you could expect to recover one 6-char every day if the passwords were randomly distributed in the 6-char alphanumeric space. So, pretty feasible, assuming a 100ms cost. Short passwords do hurt you; I agree. Now for 8-char alphanumeric passwords, you'd have to run ~1 million CPUs continuously to expect to recover one per day at a 100ms-per-pop cost. This is more of a stretch, assuming you're trying to do this with, e.g., botnets. It seems that someone asking for help cracking a password list on a forum would probably not be able to assemble this much computing power. Or 1 billion CPUs continuously to expect to recover one 10-char alphanumeric password per day. Of course, the assumption of random alphanumerics is wrong, both because many people will use common passwords and because others will use non-alphanumeric character substitution. At any rate, it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario, short of plaintext passwords.
    - tptacek 14y ago
      You are not wrong at all.
    - raverbashing 14y ago
      I didn't do the math but it sounds right. But suppose tomorrow it takes 10ms. Also, tomorrow, available spaces will increase, so the likelihood of a space vs time tradeoff (even partial) increases WEP was considered "good enough" at first (even though it had obvious problems at first like key size), WAP was considered unbreakable at first, today it's feasible with cloud computing or GPUs. And then we'll be complaining on HN that they didn't use xyzcrypt or something instead of bcrypt. " it seems to me that leaking non-salted SHA1 hashes is virtually the worst case disaster scenario" Yes. Salt is password storage 101!
      - pjscott 14y ago
tptacek 14y ago
Please stop stirring up drama about this issue. While you are technically incorrect (PBKDF2-SHA1 is faster than and thus inferior to bcrypt), it's irrelevant: all three of [scrypt, bcrypt, PBKDF2] are just fine, and you can safely pick one at random.
darkarmani 14y ago
What weakness does bcrypt have?

jere 14y ago

The reason people are going to use bcrypt is that there are more likely going to be bcrypt implementations in their given language: http://stackoverflow.com/questions/10149554/are-there-any-php-implementations-of-scrypt http://stackoverflow.com/questions/10149554/are-there-any-ph... I just had to make this choice a few days ago and bcrypt seemed like the best option with working PHP implementations. And I sure as hell am not going to try to roll my own.

jakejake 14y ago
The responses to that stack overflow question makes me want to punch somebody in the face! The #1 google response for info about Scrypt for php now points to an article arguing about the semantics of the question with no answer. Classic!