3 ms·

> You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your

> You know your password and so does the system authenticating you. Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. The difference is that there is no two passwords that collide; but there are hashes that may. And that two equal passwords from two equal users are not necessarily accessible to someone with the hash list because they are modified at rest with salts.

kevincox 3y ago
To really nitpick the server does have the password during authentication. The alternate would be a PAKE which is currently quite rare. (But probably should become the standard)
- SV_BubbleTime 3y ago
  I was going more for shouldn’t. You’re right, but for zero knowledge things like password managers where they specifically do not want your password.
  - tialaramex 3y ago
    I am aware of PAKEs, and I decided not to waste my time mentioning them because as usual the situation is: Using a PAKE correctly would be safe, but that sounds like work Just saying "Use a good password" is no work and you can pretend it's just as safe. Real world systems using a PAKE are very rare. The most notable is WPA3 (and there are numerous scenarios where it's for nothing until WPA2 is long obsolete). Lots of systems which would use a PAKE if designed by a cryptographer were instead designed by engineers or managers for whom "Ooh, a hash with salt" sounds like a sophisticated modern technical solution rather than a long obsolete one.
jamwil 3y ago
More an implementation detail than a conceptual distinction, though.
AnonHP 3y ago
> Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).
- armada651 3y ago
  > Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting). I never understood why clients are coded this way. It's trivially easy to send the salt to the client and have it do the hashing. Though I guess it doesn't really improve security in a lot of cases, because if you successfully MITM a web app you can just serve a compromised client.
  - mr_mitm 3y ago
    > I never understood why clients are coded this way. Because it makes things less secure. If it was sufficient to send the hash to the server to authenticate, and the server simply compares the hash sent by the user with the hash in its database, then the hash as actually the password. An attacker doesn't need to know the password anymore, as the hash is sufficient. Hashing was introduced precisely because some vulnerabilities allow read access to the database. With hashed passwords, the attacker in such a situation has to perform a password guessing attack first to proceed. If it was sufficient to send the hash for authentication, the attacker would not need to guess anything.
mr_mitm 3y ago
> You never submit your password, you submit that hash and they compare it. That's not true. If that were the case, the hash is now the password and the server stores it in clear text. It defeats the entire purpose of hashing passwords. Side note: that is (almost) how NTLM authentication works and why pass-the-hash is a thing in Windows networks.

kevincox 3y ago

To really nitpick the server does have the password during authentication. The alternate would be a PAKE which is currently quite rare. (But probably should become the standard)

SV_BubbleTime 3y ago
I was going more for shouldn’t. You’re right, but for zero knowledge things like password managers where they specifically do not want your password.
- tialaramex 3y ago
  I am aware of PAKEs, and I decided not to waste my time mentioning them because as usual the situation is: Using a PAKE correctly would be safe, but that sounds like work Just saying "Use a good password" is no work and you can pretend it's just as safe. Real world systems using a PAKE are very rare. The most notable is WPA3 (and there are numerous scenarios where it's for nothing until WPA2 is long obsolete). Lots of systems which would use a PAKE if designed by a cryptographer were instead designed by engineers or managers for whom "Ooh, a hash with salt" sounds like a sophisticated modern technical solution rather than a long obsolete one.

jamwil 3y ago

More an implementation detail than a conceptual distinction, though.

AnonHP 3y ago

> Nitpick, but no it shouldn’t. The HASH of your password is recorded. You never submit your password, you submit that hash and they compare it. Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting).

armada651 3y ago
> Nitpick, but the password is submitted as-is by most client applications, and the server hashes the submitted password and compares it with the hash it has (of course, with salting). I never understood why clients are coded this way. It's trivially easy to send the salt to the client and have it do the hashing. Though I guess it doesn't really improve security in a lot of cases, because if you successfully MITM a web app you can just serve a compromised client.
- mr_mitm 3y ago
  > I never understood why clients are coded this way. Because it makes things less secure. If it was sufficient to send the hash to the server to authenticate, and the server simply compares the hash sent by the user with the hash in its database, then the hash as actually the password. An attacker doesn't need to know the password anymore, as the hash is sufficient. Hashing was introduced precisely because some vulnerabilities allow read access to the database. With hashed passwords, the attacker in such a situation has to perform a password guessing attack first to proceed. If it was sufficient to send the hash for authentication, the attacker would not need to guess anything.

mr_mitm 3y ago

> You never submit your password, you submit that hash and they compare it. That's not true. If that were the case, the hash is now the password and the server stores it in clear text. It defeats the entire purpose of hashing passwords. Side note: that is (almost) how NTLM authentication works and why pass-the-hash is a thing in Windows networks.