4 ms·

Passwords should be hashed client-side anyway, so the real issue there is how to encode the password hash in a way that satisfies the legacy system. But this is

by zrm 8y ago

Passwords should be hashed client-side anyway, so the real issue there is how to encode the password hash in a way that satisfies the legacy system. But this is usually plausible, e.g. by base64 or hex encoding the hash to avoid disallowed characters and then appending specific characters that satisfy the set of required characters.

lbotos 8y ago
Do you know of any systems that actually do this? It's the first I've heard of this technique.
- zrm 8y ago
  Nothing should be doing this. Insecure legacy systems that wrongfully expect to see the plaintext of the user's password should be replaced with properly functioning ones. But just because they haven't been yet is no excuse to actually give them the plaintext of the user's password.
- A2017U1 8y ago
  It's a pointless technique as noted by others. Along the same lines though is OPAQUE PAKE, where the server doesn't need to store a password hash, only a salt, making server compromise far less dangerous, it's quite elegant. There's no implementations so far I believe. https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163
angelsl 8y ago
This just makes the password the hash of the user's passphrase.
- zrm 8y ago
  > This just makes the password the hash of the user's passphrase. There are some other advantages that others have already mentioned, but even if that was all it did it would still be useful in inhibiting an attacker from learning the actual passphrase which many users are likely to have reused on other services.
  - krapp 8y ago
    It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password, which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. Sending a password in plaintext over HTTPS is more secure than hashing it in javascript first and sending the hash.
    - zrm 8y ago
      > It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password If it's practical to find a hash collision, your hash algorithm is broken. > which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. The security of a system should not depend at all on that information being secret.
mygo 8y ago
You don’t need to hash a password over the client so long as it’s sent over an encrypted network. The goal of submitting a password is that it’s not sent in open plaintext. Otherwise even if you hash it on the client, the plaintext hash can still be intercepted and used, exactly as-is, as the plaintext password.
- 0xCMP 8y ago
  You can if you don't want the authenticating side to actually know the plain text. e.g. password + client_salt => hash => send to server => (hash+server_salt)^hash2 => compare to db By doing this you'd protect a user when their password might be accidentally logged (e.g. Twitter recently). Then if you compromise the hash you don't immediately reveal the password itself, just the text needed to authenticate, which can be changed. If you simply change the salt used client side you may not even need to have the user change their password (although obviously better if they did). That said, I don't think this is required, but there is actually a case for it. Also obviously you should never log the password, but mistakes are made. This helps mitigate the risk of that password being exposed.
  - mygo 8y ago
    I agree. So long as the plaintext hashes are hashed again on the sever, then it’s more secure.

by zrm 8y ago

lbotos 8y ago

Do you know of any systems that actually do this? It's the first I've heard of this technique.

zrm 8y ago
Nothing should be doing this. Insecure legacy systems that wrongfully expect to see the plaintext of the user's password should be replaced with properly functioning ones. But just because they haven't been yet is no excuse to actually give them the plaintext of the user's password.
A2017U1 8y ago
It's a pointless technique as noted by others. Along the same lines though is OPAQUE PAKE, where the server doesn't need to store a password hash, only a salt, making server compromise far less dangerous, it's quite elegant. There's no implementations so far I believe. https://eprint.iacr.org/2018/163 https://eprint.iacr.org/2018/163

angelsl 8y ago

This just makes the password the hash of the user's passphrase.

zrm 8y ago
> This just makes the password the hash of the user's passphrase. There are some other advantages that others have already mentioned, but even if that was all it did it would still be useful in inhibiting an attacker from learning the actual passphrase which many users are likely to have reused on other services.
- krapp 8y ago
  It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password, which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. Sending a password in plaintext over HTTPS is more secure than hashing it in javascript first and sending the hash.
  - zrm 8y ago
    > It would also be useful in finding hash collisions which would give an attacker access to a user's account without needing the actual password If it's practical to find a hash collision, your hash algorithm is broken. > which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used. The security of a system should not depend at all on that information being secret.

mygo 8y ago

You don’t need to hash a password over the client so long as it’s sent over an encrypted network. The goal of submitting a password is that it’s not sent in open plaintext. Otherwise even if you hash it on the client, the plaintext hash can still be intercepted and used, exactly as-is, as the plaintext password.

0xCMP 8y ago
You can if you don't want the authenticating side to actually know the plain text. e.g. password + client_salt => hash => send to server => (hash+server_salt)^hash2 => compare to db By doing this you'd protect a user when their password might be accidentally logged (e.g. Twitter recently). Then if you compromise the hash you don't immediately reveal the password itself, just the text needed to authenticate, which can be changed. If you simply change the salt used client side you may not even need to have the user change their password (although obviously better if they did). That said, I don't think this is required, but there is actually a case for it. Also obviously you should never log the password, but mistakes are made. This helps mitigate the risk of that password being exposed.
- mygo 8y ago
  I agree. So long as the plaintext hashes are hashed again on the sever, then it’s more secure.