[afreak]

Any developer today that is developing an application and isn't using something like Argon2, Bcrypt, or Scrypt should be considering a plan to move away from whatever they're currently using yesterday. There is no reason to be using anything less than those three and continued use is in my mind negligence.

If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication.

This should be the takeaway from this article.

[Matt3o12_]

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication.

Should we all be using "Login with LinkedIn", then?

Passwords are always difficult to deal with even when using bcrypt. Who knows if bcrypt is still considered secure in 5 years? How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins? When should you erase all passwords from inactive who haven't logged in and thus still use the old algorithm. (If you are interested in this problem, Django's user model uses a pretty straight forward and good approach[1]).

Outsourcing them is not the answer. It is a good idea to add that for the user's convenience but I hate it when websites only offer the option to login with "your" favorite social media. But even then, by outsourcing the passwords, you are risking your users' privacy by giving them to Google/Facebook/etc. This even discriminates users' privacy when they are not using Facebook for authenticating because facebook can see that user X visited your website (and sometimes even all URLs from that website you have visited). This is because those "Login with" and "Like" buttons always hit Facebook's and Google's servers with every webpage.

[1]: https://docs.djangoproject.com/en/1.9/topics/auth/passwords/

Edit: Forgot the link, thanks!

[lpage]

> Outsourcing them is not the answer

It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost certainly better off having someone do it for you.

That said, I'm with you on the social logins front. I have/had? hope for OpenID Connect as an alternative so it would be great if someone neutral like Mozilla jumped on the bandwagon.

[voycey]

The point of bcrypt though is that it is (more) future proof in that the hash generation is slow as balls and can be made exponentially slower by increasing the difficulty.

Other than some kind of algorithm weakness this slowness will translate through to the brute force attack thus taking longer for an attacker. BCrypt also has something that means it is harder for a GPU to crack it (mutable RAM memory tables or something).

As for migrating passwords - you can use a fallback password hasher that checks against a previous hash should the main one fail - then once the login is successful re-hash with the newest algorithm!

[kevin_thibedeau]

> How long would it take to implement a change which updates the hashing algorithm for new logins while still using the old algorithm for old logins?

As long as you remember to store the cost parameter along with each hash it's just a matter of increasing the default cost and reusing the old ones.

[hk__2]

> Django's user model uses a pretty straight forward and good approach[1]

You forgot to post the link.

[woodman]

> ...instead relying on another service for authentication.

If you are suggesting something like on-premises Kerberos, I agree - better yet: just design with PAM in mind. But if you are suggesting something like "login with facebook" then I have to disagree - unless your goal is to add a serious point of failure, major dependency, and huge source of information leakage all in one step.

[cm2187]

Unsalted hashes in 2012 was negligence already...

[criddell]

I complained to my bank that their 12 character password limit suggests they are storing passwords. Their reply was little more than don't worry about it, you aren't responsible for fraud. I asked for them to add some kind of second factor authentication (I'm a fan of TOTP systems) and was told they are thinking about making that available for their business accounts.

It bothers me that my most valuable login is probably my weakest.

[chinathrow]

> If at all possible you shouldn't be storing passwords to begin with and instead relying on another service for authentication

This is wrong. Using another login service might introduce all sorts of new issues, a big one is privacy.

[zeveb]

> There is no reason to be using anything less than [Argon2, bcrypt or scrypt] and continued use is in my mind negligence.

PBKDF2 is fine too.

[nojvek]

How is this better than double salted sha256. I.e sha256("secret", sha256("secret2", $pwd))

The double sha/md5 would even give rainbow tables a super hard time right?

[afreak]

PBKDF2 is not for password storage.

[sgarman]

Most of the attacks described in this article are not solved by any of those though right? They protect against hacking one person but if you just do these advanced dictionary attacks you can still crack people with weak passwords.

Maybe I'm missing something?

[afreak]

No. You cannot effectively use the techniques you can use against SHA/MD5 to attack the three I mentioned.

SHA and MD5 can be calculated entirely in a CPU's registers without having to rely on RAM. Bcrypt for example requires the use of a matrix as part of its calculation, slowing down the process. A GPU has so few channels from the processor to memory that it cannot be effectively done in parallel.

All one has to do with Bcrypt is just adjust the difficulty and any advances in GPU technology or whatever can be nullified.

[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?)

[mikeokner]

bcrypt uses unique salts per-password. The hash outputted by the bcrypt function is actually several delimited fields that have been joined into a single string.

This means that if multiple users use a common password like 'pass123', the hashes stored in the database will still each be unique. Any attacker trying to reverse all of the password hashes will have to reverse every single one individually in a targeted manner rather than using pre-computed rainbow tables or generating hashes from a wordlist and scanning the database for matching hashes.