3 ms·
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
by 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 agoNo. 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 agoCompany is stuck with ASP.
- sarciszewski 12y agohttp://www.dotnetnoob.com/2012/05/towards-more-secure-password-hashing-in.html http://www.dotnetnoob.com/2012/05/towards-more-secure-passwo...
- aerovistae 12y agoThank you!
- danielweber 12y agoIf 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 agoYep. http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...