Hacker News Reader

Hacker News

Comment by bigiain | Hacker News Reader

Parent Full thread

bigiain

They're not "solved", but they're made 3 to 6 orders of magnitude more effort:

See https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

"8x Nvidia GTX 1080 Hashcat Benchmarks"

TL;DR:

Hashtype: MD5 Speed.Dev.#.: 200.3 GH/s

Hashtype: SHA1 Speed.Dev.#.: 68771.0 MH/s

Hashtype: bcrypt, Blowfish(OpenBSD) Speed.Dev.#.: 105.7 kH/s

Hashtype: scrypt Speed.Dev.#.: 3493.6 kH/s

Hashtype: PBKDF2-HMAC-SHA512 Speed.Dev.#.: 3450.1 kH/s

Hashtype: PBKDF2-HMAC-MD5 Speed.Dev.#.: 59296.5 kH/s

You can't protect against people using "password123" or "dadada" as their passwords, but for those of us using long randomly generated passwords bcrypt makes cracking it well outside the realms of possibility for anyone short of nation-state attackers. (I bet the NSA can get quite a lot more than 100kH/s for bcrypt if they're determined enough, but I wonder if even _they_ can throw 6 orders of magnitude more compute at the task?)

View on HN

Some of these don't make sense. The point of bcrypt, scrypt, and pbkdf2 is the difficulty of them is configurable.

Digging into the comments on that gist, it says that the bcrypt benchmark used a workfactor of 5 (= 32 rounds). The lowest possible bcrypt workfactor is 4 (= 16 rounds).

For comparison, the default for the login hashes on OpenBSD is 8 (= 256 rounds) for standard accounts and 9 (= 512 rounds) for the root account, and OpenBSD's bcrypt_pbkdf(3) function uses a workfactor of 6 (= 64 rounds) and that's intended to be called with multiple rounds itself eg. in signify(1) it uses 42 rounds (a bit over the equivalent of bcrypt with a workfactor of 11) and ssh-keygen(1) defaults to 16 (roughly equivalent to bcrypt with a workfactor of 10 (= 1024 rounds).

The point I'm trying to make here is that bcrypt benchmark uses a ridiculously low workfactor, and it looks like the scrypt and pbkdf2 ones did to.

Yep - and even in it's "ridiculously low work factor" configuration, it's around 6 orders of magnitude slower than SHA. In context, the author of that piece was trying to show off the hashrate, so would be expected to err on the side of making his monster 8 gpu rig look better rather than worse.

Any of bcrypt, scrypt, or PBKDF2 can easily (as in, by design in the hash function parameters) be made however much slower is needed for you (so long as your normal login process is then still "fast enough", I had a WordPress site a while back where I couldn't wind the bcrypt plugin up much past 11 before the inexpensive webhosting would time out before login succeeded... (And yeah, feel free to mock me for "securing" WP with bcrypt - it was mostly because I wanted to be confident if/when the site got exploited, the hashes in the DB weren't going to be too easily attackable for anyone who'd used a decent password))

Reply on news.ycombinator.com