Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

> Your service should instead store a cryptographically strong hash of the password that cannot be reversed — created with, for example, PBKDF2, SHA3, Scrypt, or Bcrypt.

One of these things is not like the others, one of these things just doesn't belong

Don't use SHA3 or any other fast hash for passwords. Use a password hash designed to stymie brute-forcing, like PBKDF2, scrypt, or bcrypt.

View on HN

Million guesses per second vs thousands. Really interesting how SHA3 made its way to this blog post.

Still better than no hashing. Still a tough nut to crack if it's hashed plus salted with unique salt.

Ugh. It's supposed to be Best Practices, rather than better than nothing, and is ostensibly from Google. So should be limiting to the appropriate choices: bcrypt, scrypt, PBKDF2 or Argon2.

Not everyone can used the last hype algorithm, whether because of library support, regulations or technical constraints.

bcrypt is old enough to vote this year

still can't drink in US though

Something they acknowledge later with SMS being a bad idea, but may be the best option for a specific workflow.

glibc crypt() uses sha512, IIRC (the thing that encrypts passwords in /etc/shadow). Iterated a number of times to make it suitably expensive.

So perhaps not as good has the bespoke password hashing functions, but not a disaster waiting to happen either.

Salting and iterating would make it more reasonable, but the article (a "best practices" document) didn't say to do that, or why.

Reply on news.ycombinator.com