5 ms·

> You can't leak passwords if you don't store passwords. That's exactly why you only store password hashes in the DB. Come on, this is a solved problem! > Pro

> You can't leak passwords if you don't store passwords. 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.

gkya 10y ago
>> You can't leak passwords if you don't store passwords. > 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)?
- jhasse 10y ago
  > Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)? No, you can't compute the password from the hash.
  - MaulingMonkey 10y ago
    I'd call this dangerously un-caveated! https://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ 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.
- dsr_ 10y ago
  Depends. If you use a nice fast hash like SHA256, yes. If you use a KDF optimized for nonoptimizability like PBKDF2 or scrypt, no.
- mhluongo 10y ago
  Not if you salt and choose a strong hash algorithm. Salting is what keeps a leaked hash from hurting a user's security
  - gkya 10y ago
    Though if I have the user name and the salted hash and also access to the service providers system, can't I use those to initiate a session? I mean getting the cleartext password allows me to start a session through the UI and also try to penetrate the user's other accounts elsewhere (maybe they reused the password), but if I have the salted hash and access to the sytem, I'm still able to get a session there, no?
    - mhluongo 10y ago
      Salting is to cover password reuse across services. If you already have the keys to the kingdom for a service you can almost certainly access a user's session
    - pix64 10y ago
      When you submit the hashed password it will get re-hashed and no longer match the hashed password in the database. 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.

gkya 10y ago

>> You can't leak passwords if you don't store passwords. > 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)?

jhasse 10y ago
> Isn't leaking hashes dangerous for the users' privacy though (I'm not well-versed in security, so sorry if n00b question)? No, you can't compute the password from the hash.
- MaulingMonkey 10y ago
  I'd call this dangerously un-caveated! https://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ 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.
dsr_ 10y ago
Depends. If you use a nice fast hash like SHA256, yes. If you use a KDF optimized for nonoptimizability like PBKDF2 or scrypt, no.
mhluongo 10y ago
Not if you salt and choose a strong hash algorithm. Salting is what keeps a leaked hash from hurting a user's security
- gkya 10y ago
  Though if I have the user name and the salted hash and also access to the service providers system, can't I use those to initiate a session? I mean getting the cleartext password allows me to start a session through the UI and also try to penetrate the user's other accounts elsewhere (maybe they reused the password), but if I have the salted hash and access to the sytem, I'm still able to get a session there, no?
  - mhluongo 10y ago
    Salting is to cover password reuse across services. If you already have the keys to the kingdom for a service you can almost certainly access a user's session
  - pix64 10y ago
    When you submit the hashed password it will get re-hashed and no longer match the hashed password in the database. 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.