4 ms·

What’s wrong with hashing passwords? Hash with a slow algorithm is the best method, as far as I know

• roblabla 4y ago
  As one random point: If you just hash the password, you're vulnerable to rainbow table attacks. So you want to salt the password, at the very least. But really, what you want to do is use a framework developed by domain experts that deals with all that mess for you. Because there's a lot of surprising complexity to storing password hashes securely. So it's better to use a well-vetted library that has eyeballs and mindshare checking that it is correct.
  • junon 4y ago
    Rainbow table attacks are significantly harder with properly hashed passwords, e.g. with bcrypt.
    • SahAssar 4y ago
      I think all bcrypt implementations implement salting per default. Same for any modern password hashing implementation.
      • junon 4y ago
        That wasn't the point I was making. I was contrasting it with the (mis)use of e.g. SHA1 or worse, MD5.
    • lyu07282 4y ago
      I think that's what they are saying, bcrypt is secure because it uses a salt and multiple rounds of hashing.
• tialaramex 4y ago
  Avoid passwords. "A secret is something you tell one other person, so I'm telling you". If possible adjust APIs to not rely on knowledge of secrets for their functioning, and then this entire problem evaporates. e.g. WebAuthn. If it's crucial that a human memorable secret (a password) is used, choose an asymmetrical Password Authenticated Key Exchange in which it's possible for the relying party to learn a value with which they can confirm that the other party knows the password, but never learn what that password is. This is really difficult to do properly, OPAQUE is the current recommendation of the IETF for this purpose. Only fall back to hashing passwords because you're obliged to for legacy reasons.
  • FreakLegion 4y ago
    PAKEs bring little to the table when looked at in context of an actual threat model[1], meanwhile they add a fair degree of complexity and their implementations are much less battle-tested. Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up. Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords". 1. https://palant.info/2018/10/25/should-your-next-web-based-login-form-avoid-sending-passwords-in-clear-text/ https://palant.info/2018/10/25/should-your-next-web-based-lo...
    • staticassertion 4y ago
      > Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up. The main benefit of PAKE is avoiding accidental logging of passwords, which absolutely happens at organizations all the time. ZKP is a fine approach, although you can avoid much of the issue with something simpler (addressing a narrower threat, but the most relevant piece).
    • tialaramex 4y ago
      > Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords". It seems like you've no idea how WebAuthn works, or why it's such an important improvement. That's fine, but probably better to just tell people "I know nothing about this" rather than pretend to know enough to give a recommendation. > PAKEs bring little to the table when looked at in context of an actual threat model The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed.
      • FreakLegion 4y ago
        WebAuthn can be used with or without a password. You said "avoid passwords", and mentioned WebAuthn. I simply clarified "don't avoid passwords with WebAuthn". By all means use WebAuthn, but ideally keep the password, too. > The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed. You have correctly deduced that my comment on PAKEs was a response to your comment on PAKEs and not a criticism of WebAuthn. I believe I can say with confidence that we both think WebAuthn is great.
• staticassertion 4y ago
  Nothing, it's an example of good advice we give developers. I made a mistake it in my first post.