3 ms·

I was under the impression SHA256 is valid...it's a cryptographic hash function that hasn't had weaknesses identified yet. 40 iterations of that + salting would

I was under the impression SHA256 is valid...it's a cryptographic hash function that hasn't had weaknesses identified yet. 40 iterations of that + salting would suffice, no?

aerovistae 12y ago
I do realize bcrypt is arguably the best option, but why is SHA not valid also?
- tptacek 12y ago
  Because it has no work factor. It's uniformly fast, which makes it very easy to brute force. The general-purpose strong cryptographic hashes --- your SHA2s, SHA3s, and BLAKE2s --- are all amenable to fast implementation on GPU. What you need is a password hash, not merely a cryptographic hash.
  - aerovistae 12y ago
    As noted above, this discussion prompted me to investigate my company's methods, a fairly major US website, and I found they're using SHA-256 for 50 iterations with salting. Does that slow things down sufficiently, or is that not comparable to the internal mechanism of bcrypt?
    - sarciszewski 12y ago
      No. Currently, PBKDF2 (which iterates HMAC-SHA1, HMAC-SHA256, etc.) typically is used with a count in the thousands. I'd recommend upgrading to follow best standards. If you use PHP, scrypt isn't that hard to set up. https://scott.arciszewski.me/blog/2013/10/php-scrypt-setup https://scott.arciszewski.me/blog/2013/10/php-scrypt-setup
    - aerovistae 12y ago
      Company is stuck with ASP.
      - sarciszewski 12y ago
        http://www.dotnetnoob.com/2012/05/towards-more-secure-password-hashing-in.html http://www.dotnetnoob.com/2012/05/towards-more-secure-passwo...
      - aerovistae 12y ago
        Thank you!
      - danielweber 12y ago
        If you change 50 to (say) 1000 you are getting most of the benefits. The big problem you are trying to solve is "our password database just leaked; how fast can attackers figure out the passwords?" Say you can run SHA in 1 microsecond, and 1000 iterations in 1 millisecond. Even though it's 1000x slower, that's probably an unnoticeable difference as far as your performance is concerned. (YMMV) But, anyone trying to brute-force the passwords out of your database will now have to do 1000x the work. BTW, none of this will help you much if your users choose passwords like "abc" or "password". (IIRC scrypt lets you blow up in size as well as CPU, which makes GPUs impractical for attacking.)
        sarciszewski 12y ago
        Yep. http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...
- mikeash 12y ago
  Because a lot of passwords aren't particularly strong, and thus are feasibly crackable when you use something like SHA-256. You can test millions or billions of candidates per second on commodity hardware, and you'll be able to recover a lot of passwords. The purpose of systems like PBKDF2, bcrypt, scrypt, etc. is to intentionally slow the whole thing down so that it takes on the order of one second to test a candidate. This is a minor burden for normal use, since you don't check passwords very often, but it makes it vastly harder for an attacker to crack a password. Edit: just to put some numbers on this, it looks like high-end GPUs can brute-force about 2 billion SHA-256 hashes per second. That means that an eight-character alphanumeric password could be recovered from a SHA-256 hash in less than a day, on average. Add 20 non-alphanumeric symbols to your character set and you're still only looking at about six days. Eight alpha+num+symbol characters isn't a terribly great password anymore but it still shouldn't be recoverable if your password database leaks.
Alupis 12y ago
the SHA algorithms were designed to digest data as fast as possible -- which things like bcrypt purposefully slow it down plus can perform multiple iterations with the output of one iteration feeding as the input to another. Here is some more info: http://forums.udacity.com/questions/6016855/hashing-passwords-using-sha256-is-not-enough-today http://forums.udacity.com/questions/6016855/hashing-password...
sarciszewski 12y ago
If you're going to use SHA256 for hashing, why not use it in PBKDF2-SHA256? https://defuse.ca/php-pbkdf2.htm https://defuse.ca/php-pbkdf2.htm

I was under the impression SHA256 is valid...it's a cryptographic hash function that hasn't had weaknesses identified yet. 40 iterations of that + salting would suffice, no?

aerovistae 12y ago

I do realize bcrypt is arguably the best option, but why is SHA not valid also?

tptacek 12y ago
Because it has no work factor. It's uniformly fast, which makes it very easy to brute force. The general-purpose strong cryptographic hashes --- your SHA2s, SHA3s, and BLAKE2s --- are all amenable to fast implementation on GPU. What you need is a password hash, not merely a cryptographic hash.
- aerovistae 12y ago
  As noted above, this discussion prompted me to investigate my company's methods, a fairly major US website, and I found they're using SHA-256 for 50 iterations with salting. Does that slow things down sufficiently, or is that not comparable to the internal mechanism of bcrypt?
  - sarciszewski 12y ago
    No. Currently, PBKDF2 (which iterates HMAC-SHA1, HMAC-SHA256, etc.) typically is used with a count in the thousands. I'd recommend upgrading to follow best standards. If you use PHP, scrypt isn't that hard to set up. https://scott.arciszewski.me/blog/2013/10/php-scrypt-setup https://scott.arciszewski.me/blog/2013/10/php-scrypt-setup
  - aerovistae 12y ago
    Company is stuck with ASP.
    - sarciszewski 12y ago
      http://www.dotnetnoob.com/2012/05/towards-more-secure-password-hashing-in.html http://www.dotnetnoob.com/2012/05/towards-more-secure-passwo...
    - aerovistae 12y ago
      Thank you!
    - danielweber 12y ago
      If you change 50 to (say) 1000 you are getting most of the benefits. The big problem you are trying to solve is "our password database just leaked; how fast can attackers figure out the passwords?" Say you can run SHA in 1 microsecond, and 1000 iterations in 1 millisecond. Even though it's 1000x slower, that's probably an unnoticeable difference as far as your performance is concerned. (YMMV) But, anyone trying to brute-force the passwords out of your database will now have to do 1000x the work. BTW, none of this will help you much if your users choose passwords like "abc" or "password". (IIRC scrypt lets you blow up in size as well as CPU, which makes GPUs impractical for attacking.)
      - sarciszewski 12y ago
        Yep. http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...
mikeash 12y ago
Because a lot of passwords aren't particularly strong, and thus are feasibly crackable when you use something like SHA-256. You can test millions or billions of candidates per second on commodity hardware, and you'll be able to recover a lot of passwords. The purpose of systems like PBKDF2, bcrypt, scrypt, etc. is to intentionally slow the whole thing down so that it takes on the order of one second to test a candidate. This is a minor burden for normal use, since you don't check passwords very often, but it makes it vastly harder for an attacker to crack a password. Edit: just to put some numbers on this, it looks like high-end GPUs can brute-force about 2 billion SHA-256 hashes per second. That means that an eight-character alphanumeric password could be recovered from a SHA-256 hash in less than a day, on average. Add 20 non-alphanumeric symbols to your character set and you're still only looking at about six days. Eight alpha+num+symbol characters isn't a terribly great password anymore but it still shouldn't be recoverable if your password database leaks.

Alupis 12y ago

the SHA algorithms were designed to digest data as fast as possible -- which things like bcrypt purposefully slow it down plus can perform multiple iterations with the output of one iteration feeding as the input to another. Here is some more info: http://forums.udacity.com/questions/6016855/hashing-passwords-using-sha256-is-not-enough-today http://forums.udacity.com/questions/6016855/hashing-password...

sarciszewski 12y ago

If you're going to use SHA256 for hashing, why not use it in PBKDF2-SHA256? https://defuse.ca/php-pbkdf2.htm https://defuse.ca/php-pbkdf2.htm