4 ms·

> Use a slow, secure hash function like SHA-256. Don't use MD5! Don't use a single round of any hash function, including SHA-256. You shouldn't try to roll yo

> Use a slow, secure hash function like SHA-256. Don't use MD5! Don't use a single round of any hash function, including SHA-256. You shouldn't try to roll your own crypto, and you shouldn't try to roll your own password verification either. Use bcrypt and you'll get salting and you'll get a multi-round hashing process that has the ability to easily scale up in complexity as computing power continues to increase.

chronid 12y ago
This. Absolutely this. Also see [1]. [1] http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
benburwell 12y ago
I actually just updated the article to reflect this. bcrypt is a much better solution than what I originally proposed. Thanks!
- TheSwordsman 12y ago
  I gotta ask, how many systems/websites have you actually maintained in a production environment? I like people offering help to others, but I read your article before you updated this... and I immediately wrote you off because of that. It's great to offer advice, but can't seem to find any indication of what your experience is.
- TheSwordsman 12y ago
  Nevermind, answered my own question.
markdown 12y ago
Except if you can't use bcrypt. Eg. on Google App Engine.
- unepipe 12y ago
  When Google is doing your authentication for you? This node is about rolling your own auth.
  - markdown 12y ago
    Not everyone has a Gmail account, so if your app is of any consequence, you won't use Google auth on GAE. You'll roll your own. GAE won't let you upload and run modules that are C-based, so bcrypt is out of the question.
unepipe 12y ago
Being incorrect in one area is often indicative of wrong thinking in many areas. The recommendation to use SHA-256 is dangerous and it makes me distrust the entire post.
tracker1 12y ago
There's a few minor issues with something like bcrypt, it is computationally expensive for the server as well as the client... if you set things marginally high, it's a relatively easy point of not just login attack, but a DDOS attack surface as well. You could do a shadow hash, that's intentionally weak (high chance of conflicts) or even a bitwise composite as an early check to see if a password matches the first check before doing the full bcrypt attempt... you'll also need to do a random wait before returning a result that resembles a full server-side check to reduce timing attacks. You can also either move the computation to the client over a secure channel, or have another challenge/response method in place. I've actually thought about having a bcrypt challenge/response (from a pool of known values at the server) in order to reduce abuse of an API structure or interface. It was a thought exercise in how to approach such a method better... It was actually a thought on how to approach something like a next generation hive/bittorrent protocol to reduce the attack surface a bit. In any case, just be careful when you implement more secure hashes with a high compute cost... it can bite you in the ass if you aren't careful.
- lazyjones 12y ago
  > if you set things marginally high, it's a relatively easy point of not just login attack, but a DDOS attack surface as well That's no excuse for using a worse hashing method. You need to rate-limit login attempts anyway to prevent (or at least make impractical) brute forcing / dictionary attack attempts. But it's a can of worms either way (next step is captchas because of tor / anonymizer proxies etc.).
cheald 12y ago
Not just that, but SHA-256 isn't slow. It's slower than CRC or MD5, sure, but it's slowness isn't a feature like blowfish's is. A single round of Blowfish, by comparison, takes time to set up the key and IV that SHA256 doesn't; bcrypt compounds that. According to http://www.cryptopp.com/benchmarks.html http://www.cryptopp.com/benchmarks.html you could check ~6480 bytes of SHA256 in the time that it would take you to just set up your first blowfish check. If you're trying to brute-force an 8-character password, you're looking at 141 cycles per password for SHA256 and 114,950 cycles per password for a single round of blowfish.

chronid 12y ago

This. Absolutely this. Also see [1]. [1] http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/

benburwell 12y ago

I actually just updated the article to reflect this. bcrypt is a much better solution than what I originally proposed. Thanks!

TheSwordsman 12y ago
I gotta ask, how many systems/websites have you actually maintained in a production environment? I like people offering help to others, but I read your article before you updated this... and I immediately wrote you off because of that. It's great to offer advice, but can't seem to find any indication of what your experience is.
TheSwordsman 12y ago
Nevermind, answered my own question.

markdown 12y ago

Except if you can't use bcrypt. Eg. on Google App Engine.

unepipe 12y ago
When Google is doing your authentication for you? This node is about rolling your own auth.
- markdown 12y ago
  Not everyone has a Gmail account, so if your app is of any consequence, you won't use Google auth on GAE. You'll roll your own. GAE won't let you upload and run modules that are C-based, so bcrypt is out of the question.

unepipe 12y ago

Being incorrect in one area is often indicative of wrong thinking in many areas. The recommendation to use SHA-256 is dangerous and it makes me distrust the entire post.

tracker1 12y ago

There's a few minor issues with something like bcrypt, it is computationally expensive for the server as well as the client... if you set things marginally high, it's a relatively easy point of not just login attack, but a DDOS attack surface as well. You could do a shadow hash, that's intentionally weak (high chance of conflicts) or even a bitwise composite as an early check to see if a password matches the first check before doing the full bcrypt attempt... you'll also need to do a random wait before returning a result that resembles a full server-side check to reduce timing attacks. You can also either move the computation to the client over a secure channel, or have another challenge/response method in place. I've actually thought about having a bcrypt challenge/response (from a pool of known values at the server) in order to reduce abuse of an API structure or interface. It was a thought exercise in how to approach such a method better... It was actually a thought on how to approach something like a next generation hive/bittorrent protocol to reduce the attack surface a bit. In any case, just be careful when you implement more secure hashes with a high compute cost... it can bite you in the ass if you aren't careful.

lazyjones 12y ago
> if you set things marginally high, it's a relatively easy point of not just login attack, but a DDOS attack surface as well That's no excuse for using a worse hashing method. You need to rate-limit login attempts anyway to prevent (or at least make impractical) brute forcing / dictionary attack attempts. But it's a can of worms either way (next step is captchas because of tor / anonymizer proxies etc.).

cheald 12y ago

Not just that, but SHA-256 isn't slow. It's slower than CRC or MD5, sure, but it's slowness isn't a feature like blowfish's is. A single round of Blowfish, by comparison, takes time to set up the key and IV that SHA256 doesn't; bcrypt compounds that. According to http://www.cryptopp.com/benchmarks.html http://www.cryptopp.com/benchmarks.html you could check ~6480 bytes of SHA256 in the time that it would take you to just set up your first blowfish check. If you're trying to brute-force an 8-character password, you're looking at 141 cycles per password for SHA256 and 114,950 cycles per password for a single round of blowfish.