3 ms·

Bcrypt (or scrypt) should actually be used as default for password hashing in application servers. Using something like crypt/md5/sha-1 hashing per default is j

by gst 16y ago

Bcrypt (or scrypt) should actually be used as default for password hashing in application servers. Using something like crypt/md5/sha-1 hashing per default is just completely irresponsible.

cdavid 16y ago
Why bcrypt should be used instead of sha-1 ? (I am genuily asking, I don't know anything about security).
- SoftwareMaven 16y ago
  http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- Groxx 16y ago
  Essentially, because it's slow. SHA is designed to be fast, so dictionary attacks can find huge amounts of matches nigh-instantly, and rainbow tables (or GPU EC2 instances!) exist to brute-force up to 8-12 characters, more than enough to crack most people's passwords. You can salt the hash (basically: pre-pend a unique string to the password) to defeat rainbow tables, but SHA doesn't do this by default. You can SHA something more than once to slow things down, but SHA doesn't do this by default (and rainbow tables still work - they're based on repeated hashings). BCrypt is slow by design (ie, thousands of times slower). It's a much-harder calculation, and it automatically uniquely salts what it's hashing, and you can make it more secure incrementally by simply running it through more steps (it's designed to do this). The speed isn't noticeable to a user while logging in because checking if their password is correct is still extremely quick, but attempted-brute-forcers run up against a brick wall as their attempts are now rainbow-table-proof and slower by orders of magnitude. Best of all: it does all this by default, and it stores all the necessary information in the result so comparing values against it is fool-proof. You can't mis-use it. SCrypt takes all the advantages of BCrypt and goes a step further: it guarantees that a certain amount of memory (ie, large) is required to perform the hashing function. So while SHA / BCrypt can still be attacked more quickly by, say, performing a thousand operations at a time through custom hardware, SCrypt can demand so much memory that it's simply infeasible to do so, so you're stuck testing one. password. at. a. time. It's the ultimate death to brute-forcing, basically.
cookiecaper 16y ago
You know, I know that bcrypt is the cool new thing, but I don't think it's really that irresponsible, and certainly not completely irresponsible, to use a hashing scheme with a huge salt. I understand that bcrypt is super slow and therefore super awesome since the bad guy will have to sit around longer to decrypt your whole database, but maybe we should be a bit more careful with things that are termed "completely irresponsible". Something may be adequate and not be the best option, and something may be inadequate but not be "completely irresponsible". For an example of complete and wanton irresponsibility, see Plenty of Fish.
- tptacek 16y ago
  Big salt, little salt, smoked salt, epsom salt. Nothing you can do with your salt protects you from the attack that bcrypt protects you from, which is the same attack that harvested passwords from the Gawker hashes.
  - cookiecaper 16y ago
    Can you provide more detail? That doesn't mesh with my understanding. The Gawker hacks are different in a couple of ways. First, they had access to the complete Gawker database, could have downloaded it and run their attacks on their side. They still would have needed to use blowfish/bcrypt (afaik), but your high rounds are useless if an attacker gets the actual data out of your infrastructure, just like they are with normaler hashes. Second, the Gawker guys had no salting, and they used DES, which, as you know, was deprecated before many HN users were born. This made cracking the passwords really easy ... not that it would be that much harder with a conventional salting mechanism or even with bcrypt. I was not contending that bcrypt is not like really great, just that it's not "completely irresponsible" to not use bcrypt or scrypt. bcrypt is still vulnerable to dictionary attacks, the only difference is the amount of time it will take to get everyone's password out, which, again, is useless in a case like gawker where the dumps are distributed all over the internet for anyone with an interest to peruse. Please correct me if I'm wrong.
    - tptacek 16y ago

by gst 16y ago

Bcrypt (or scrypt) should actually be used as default for password hashing in application servers. Using something like crypt/md5/sha-1 hashing per default is just completely irresponsible.

cdavid 16y ago

Why bcrypt should be used instead of sha-1 ? (I am genuily asking, I don't know anything about security).

SoftwareMaven 16y ago
http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
Groxx 16y ago
Essentially, because it's slow. SHA is designed to be fast, so dictionary attacks can find huge amounts of matches nigh-instantly, and rainbow tables (or GPU EC2 instances!) exist to brute-force up to 8-12 characters, more than enough to crack most people's passwords. You can salt the hash (basically: pre-pend a unique string to the password) to defeat rainbow tables, but SHA doesn't do this by default. You can SHA something more than once to slow things down, but SHA doesn't do this by default (and rainbow tables still work - they're based on repeated hashings). BCrypt is slow by design (ie, thousands of times slower). It's a much-harder calculation, and it automatically uniquely salts what it's hashing, and you can make it more secure incrementally by simply running it through more steps (it's designed to do this). The speed isn't noticeable to a user while logging in because checking if their password is correct is still extremely quick, but attempted-brute-forcers run up against a brick wall as their attempts are now rainbow-table-proof and slower by orders of magnitude. Best of all: it does all this by default, and it stores all the necessary information in the result so comparing values against it is fool-proof. You can't mis-use it. SCrypt takes all the advantages of BCrypt and goes a step further: it guarantees that a certain amount of memory (ie, large) is required to perform the hashing function. So while SHA / BCrypt can still be attacked more quickly by, say, performing a thousand operations at a time through custom hardware, SCrypt can demand so much memory that it's simply infeasible to do so, so you're stuck testing one. password. at. a. time. It's the ultimate death to brute-forcing, basically.

cookiecaper 16y ago

You know, I know that bcrypt is the cool new thing, but I don't think it's really that irresponsible, and certainly not completely irresponsible, to use a hashing scheme with a huge salt. I understand that bcrypt is super slow and therefore super awesome since the bad guy will have to sit around longer to decrypt your whole database, but maybe we should be a bit more careful with things that are termed "completely irresponsible". Something may be adequate and not be the best option, and something may be inadequate but not be "completely irresponsible". For an example of complete and wanton irresponsibility, see Plenty of Fish.

tptacek 16y ago
Big salt, little salt, smoked salt, epsom salt. Nothing you can do with your salt protects you from the attack that bcrypt protects you from, which is the same attack that harvested passwords from the Gawker hashes.
- cookiecaper 16y ago
  Can you provide more detail? That doesn't mesh with my understanding. The Gawker hacks are different in a couple of ways. First, they had access to the complete Gawker database, could have downloaded it and run their attacks on their side. They still would have needed to use blowfish/bcrypt (afaik), but your high rounds are useless if an attacker gets the actual data out of your infrastructure, just like they are with normaler hashes. Second, the Gawker guys had no salting, and they used DES, which, as you know, was deprecated before many HN users were born. This made cracking the passwords really easy ... not that it would be that much harder with a conventional salting mechanism or even with bcrypt. I was not contending that bcrypt is not like really great, just that it's not "completely irresponsible" to not use bcrypt or scrypt. bcrypt is still vulnerable to dictionary attacks, the only difference is the amount of time it will take to get everyone's password out, which, again, is useless in a case like gawker where the dumps are distributed all over the internet for anyone with an interest to peruse. Please correct me if I'm wrong.
  - tptacek 16y ago