4 ms·

It's pretty easy to keep a list of old salted hashes, and copmare the new password's salted hash against the previous ones. It doesn't require saving the old pa

by e28eta 10y ago

It's pretty easy to keep a list of old salted hashes, and copmare the new password's salted hash against the previous ones. It doesn't require saving the old passwords.

ikeboy 10y ago
If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.
- niftich 10y ago
  I don't follow what you're saying. To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
  - ikeboy 10y ago
    If everything is done server side, sure.
    - niftich 10y ago
      Why wouldn't it be? If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in. So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
      - ikeboy 10y ago
        >Why wouldn't it be? So that the server never gets any plaintext. >So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place. You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
        icebraining 10y ago
        I don't see what hashing on the client gets you.
        ikeboy 10y ago
        >So that the server never gets any plaintext. Mitigates attacks that exploit the server but not the served js. See also https://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server. I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing. How can it hurt? If there's no harm, but some upside, then why not?
        icebraining 10y ago
        Since the resulting hash must be deterministic, you can't use a salt, and since you may login from crappy smartphones without JIT engines, you can't use many rounds. So the resulting hash will be trivially cracked using rainbow tables. The problem of variable-length passwords is better solved by only allowing the use of block ciphers in your TLS configuration, which you should probably do anyway. As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
        ikeboy 10y ago
        >Since the resulting hash must be deterministic, you can't use a salt You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables. I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes. Logins take longer: a single hash+salt won't make a big difference even on low end devices. Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional. Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).

by e28eta 10y ago

It's pretty easy to keep a list of old salted hashes, and copmare the new password's salted hash against the previous ones. It doesn't require saving the old passwords.

ikeboy 10y ago

If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.

niftich 10y ago
I don't follow what you're saying. To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
- ikeboy 10y ago
  If everything is done server side, sure.
  - niftich 10y ago
    Why wouldn't it be? If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in. So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
    - ikeboy 10y ago
      >Why wouldn't it be? So that the server never gets any plaintext. >So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place. You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
      - icebraining 10y ago
        I don't see what hashing on the client gets you.
        ikeboy 10y ago
        >So that the server never gets any plaintext. Mitigates attacks that exploit the server but not the served js. See also https://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server. I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing. How can it hurt? If there's no harm, but some upside, then why not?
        icebraining 10y ago
        Since the resulting hash must be deterministic, you can't use a salt, and since you may login from crappy smartphones without JIT engines, you can't use many rounds. So the resulting hash will be trivially cracked using rainbow tables. The problem of variable-length passwords is better solved by only allowing the use of block ciphers in your TLS configuration, which you should probably do anyway. As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
        ikeboy 10y ago
        >Since the resulting hash must be deterministic, you can't use a salt You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables. I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes. Logins take longer: a single hash+salt won't make a big difference even on low end devices. Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional. Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).