Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Storing password hashes in an inappropriate manner

The problem isn't how you store the hash it's how you generate the hash.



Counterexample: Storing the bcrypt hash by appending it to a CSV file containing the usernames and hashes of all users then having a login process where that CSV file is downloaded to the client and the password is verified locally against that CSV file using client-side JavaScript would probably be very bad.

Cryptography part is fine but storage or the auth process isn't.

You would like to think that no-one would write their app that way, but there are plenty of slightly less worse things that happen in practice and vibe coding probably introduces all sorts of new silliness.


The short answer: Bcrypt with 12 rounds.

Good enough for almost any startup in 2025.


Argon2 with defaults. Stronger and easier.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: