> That's exactly why you only store password hashes in the DB. Come on, this is a solved problem!
Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)?
I'm not sure what you mean by having access to the system. If you have write access to the database you can just change the user's password to whatever you want.
No, you can't compute the password from the hash.
https://arstechnica.com/security/2012/12/25-gpu-cluster-crac...
If your users passwords are sufficiently weak (and let's face it - they are) they can likely be brute forced and then matched against leaked hashes, no matter how strong your salt and hash. If you've got good users who only give you "typically" weak passwords, weak unsalted hashes will still expose said passwords.
Use a strong hash. Perhaps run multiple times, bcrypt style. Salt correctly, and per-user. Somehow convince your users to actually use strong, non-reused passwords. Perhaps then there's no danger to leaking the hashes - but I'd perhaps err on the side of caution and not make the password database publicly readable nonetheless.
That's exactly why you only store password hashes in the DB. Come on, this is a solved problem!
> Pro: less implementation effort
Sure. But how much of your app's total dev effort is it? Nothing.
I hate the UX of having to log in by email.