4 ms·

Right, but you are missing the point. This is a thread about revealing a users "choosen password" to a fake or compromised server. If you aren't going to fully

by pests 6y ago

Right, but you are missing the point. This is a thread about revealing a users "choosen password" to a fake or compromised server. If you aren't going to fully implement SRP like you mentioned, I'd rather a server only see a hash than my actual "chosen password". I understand the hash becomes the password to that server. That's okay. But each server gets its own hash that's unique. It cant be correlated in dumps or used on our her sites with the same email. That server can now never know the password my grandma also uses for her email, bank. and every other website across the internet.

rl3 6y ago
Thanks. That was a really clear and concise explanation.
thaumasiotes 6y ago
> I understand the hash becomes the password to that server. That's okay. But each server gets its own hash that's unique. It cant be correlated in dumps or used on [other] sites with the same email. First: > It cant be correlated in dumps Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. > or used on [other] sites with the same email. This depends on how Mallory obtained the password. It was already hashed and salted server-side. So consider the example where the user entered a simple password P, the client side hashed P to become C, and the server side rehashed C to become S. C is what went over the wire. If the server is compromised and the password database is dumped, Mallory gets a bunch of random-looking hashes. She has to crack those. She could do that by enumerating the space of C possibilities -- very long random strings of binary data -- and hashing them once. Or she could do that by enumerating the space of P possibilities -- the things a user types in order to log in -- and hashing them twice.[1] The first option is essentially impossible. But the second option is easy. (Assuming your grandma used a password that is easy to guess.) Mallory will use the second option. And the password she learns from that approach will transfer perfectly to every other website. [1] rl3 mentioned salting the user-password client-side. If the user is allowed to log in from multiple machines, then this salt must be stored on the server (so that it can be communicated to the user when the user attempts to log in from a new machine), and will be available to the attacker who's compromised the server.
- rl3 6y ago
  >Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. Yet it does help, because if your server is exploited, the attacker can potentially read the plaintext/cleartext passwords as they're received from the client. >... and will be available to the attacker who's compromised the server. Not necessarily. It depends on the nature of the server compromise. Exploit scope is often limited.
  - thaumasiotes 6y ago
    >> Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. > Yet it does help, because if your server is exploited, the attacker can potentially read the plaintext/cleartext passwords as they're received from the client. I can't tell if you're agreeing with me and claiming that the client-side hash is valuable for reasons pests didn't mention ("yet it does help"), or disagreeing with me and claiming that the client-side hash is valuable for the reasons pests states. ("yes it does help"). But you have commented elsewhere that you believe pests is correct ( https://news.ycombinator.com/item?id=24027030 https://news.ycombinator.com/item?id=24027030 ), so I'll note here that reading the password the user typed, straight off a compromised TLS connection, has nothing to do with correlating dumped password hashes. If you can see the user's password, you don't need to learn that password by matching its hash up against the hash of someone else whose password you already know. (And you can't hash the password you read to compare with other hashes stored in the database, because those other hashes are salted.) With the server-side hash already blocking this attack, the client-side hash is adding absolutely nothing.
    - rl3 6y ago
      >With the server-side hash already blocking this attack, the client-side hash is adding absolutely nothing. We're saying that the protection afforded by server hashing schemes can in some cases be completely bypassed by raw user password input being present on the server when it arrives from the client. You're saying client-side hashing adds absolutely nothing, on the grounds that all hash function input is known because it is the client, and that it may as well be plaintext at that point. I disagree that all input is necessarily known, and that the nature of the server exploit as well as client/server architecture, topology, and client hashing scheme all factor in to whether this is the case. If it is true that client-side hashing is beneficial in some cases, then it is also true that it does not add absolutely nothing. Good security is layered. Moreover, it in no way obviates the need for server-side hashing, nor TLS. For all practical purposes, using a zero-knowledge scheme such as SRP is a much better solution, but that still doesn't render client-side hashing completely pointless. https://crypto.stackexchange.com/questions/25338/why-arent-zero-knowledge-proofs-used-in-practice-for-authentication https://crypto.stackexchange.com/questions/25338/why-arent-z... The first two bullet points in that reply are especially salient to this discussion.

by pests 6y ago

rl3 6y ago

Thanks. That was a really clear and concise explanation.

thaumasiotes 6y ago

> I understand the hash becomes the password to that server. That's okay. But each server gets its own hash that's unique. It cant be correlated in dumps or used on [other] sites with the same email. First: > It cant be correlated in dumps Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. > or used on [other] sites with the same email. This depends on how Mallory obtained the password. It was already hashed and salted server-side. So consider the example where the user entered a simple password P, the client side hashed P to become C, and the server side rehashed C to become S. C is what went over the wire. If the server is compromised and the password database is dumped, Mallory gets a bunch of random-looking hashes. She has to crack those. She could do that by enumerating the space of C possibilities -- very long random strings of binary data -- and hashing them once. Or she could do that by enumerating the space of P possibilities -- the things a user types in order to log in -- and hashing them twice.[1] The first option is essentially impossible. But the second option is easy. (Assuming your grandma used a password that is easy to guess.) Mallory will use the second option. And the password she learns from that approach will transfer perfectly to every other website. [1] rl3 mentioned salting the user-password client-side. If the user is allowed to log in from multiple machines, then this salt must be stored on the server (so that it can be communicated to the user when the user attempts to log in from a new machine), and will be available to the attacker who's compromised the server.

rl3 6y ago
>Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. Yet it does help, because if your server is exploited, the attacker can potentially read the plaintext/cleartext passwords as they're received from the client. >... and will be available to the attacker who's compromised the server. Not necessarily. It depends on the nature of the server compromise. Exploit scope is often limited.
- thaumasiotes 6y ago
  >> Hashing client-side doesn't help with that. The password already couldn't be correlated in dumps, because it was salted server-side. > Yet it does help, because if your server is exploited, the attacker can potentially read the plaintext/cleartext passwords as they're received from the client. I can't tell if you're agreeing with me and claiming that the client-side hash is valuable for reasons pests didn't mention ("yet it does help"), or disagreeing with me and claiming that the client-side hash is valuable for the reasons pests states. ("yes it does help"). But you have commented elsewhere that you believe pests is correct ( https://news.ycombinator.com/item?id=24027030 https://news.ycombinator.com/item?id=24027030 ), so I'll note here that reading the password the user typed, straight off a compromised TLS connection, has nothing to do with correlating dumped password hashes. If you can see the user's password, you don't need to learn that password by matching its hash up against the hash of someone else whose password you already know. (And you can't hash the password you read to compare with other hashes stored in the database, because those other hashes are salted.) With the server-side hash already blocking this attack, the client-side hash is adding absolutely nothing.
  - rl3 6y ago
    >With the server-side hash already blocking this attack, the client-side hash is adding absolutely nothing. We're saying that the protection afforded by server hashing schemes can in some cases be completely bypassed by raw user password input being present on the server when it arrives from the client. You're saying client-side hashing adds absolutely nothing, on the grounds that all hash function input is known because it is the client, and that it may as well be plaintext at that point. I disagree that all input is necessarily known, and that the nature of the server exploit as well as client/server architecture, topology, and client hashing scheme all factor in to whether this is the case. If it is true that client-side hashing is beneficial in some cases, then it is also true that it does not add absolutely nothing. Good security is layered. Moreover, it in no way obviates the need for server-side hashing, nor TLS. For all practical purposes, using a zero-knowledge scheme such as SRP is a much better solution, but that still doesn't render client-side hashing completely pointless. https://crypto.stackexchange.com/questions/25338/why-arent-zero-knowledge-proofs-used-in-practice-for-authentication https://crypto.stackexchange.com/questions/25338/why-arent-z... The first two bullet points in that reply are especially salient to this discussion.