Hacker News Reader

Comment by JonathonW | Hacker News Reader

> 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.

View on HN

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

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.

Nevermind, answered my own question.

This. Absolutely this. Also see [1].

[1] http://codahale.com/how-to-safely-store-a-password/

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.

> 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.).

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 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.

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

When Google is doing your authentication for you? This node is about rolling your own auth.

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.

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.

Reply on news.ycombinator.com