4 ms·

>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

by 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.
  - thaumasiotes 6y ago
    First, decide what you're talking about. Then, say something about it. You're obviously not talking about correlating hashes in password dumps here. What are you talking about? > 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. No, this is just gibberish you made up to put in my mouth.
    - rl3 6y ago
      >What are you talking about? The utility of client-side hashing. >No, this is just gibberish you made up to put in my mouth. It was actually a good faith attempt to frame your argument.
      - thaumasiotes 6y ago
        >> What are you talking about? > The utility of client-side hashing. You have responded in the wrong place. Let's start over. pests claimed that performing a client-side salt/hash in addition to a server-side salt/hash has two benefits: P1: User passwords on the server can't be correlated with other passwords in database dumps. P2: Knowing a user's password on the site so protected will not let you learn the user's password on other, third-party websites. But claim P1 is nonsense. It is true that user passwords on the server can't be correlated with other passwords in database dumps. But client-side hashing has nothing to do with that. If the client-side hashing were not performed at all, it would still be impossible to correlate user passwords with other passwords in database dumps. Claim P2 is shaky. It's correct that -- if the method of learning a user's password is to read their active TLS connection with the server -- the password learned by that method will not be useful on other third-party websites. But it does not apply if the attacker's method of learning the user's password was by cracking a password entry in a database dump. The password learned by that method will be whatever the user typed originally, not the hash of it received by the server. What is the value that you perceive in claims P1 and P2? ("Thanks. That was a really clear and concise explanation.") Why are we describing an entirely spurious claim as "clear"?

by rl3 6y ago

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.
- thaumasiotes 6y ago
  First, decide what you're talking about. Then, say something about it. You're obviously not talking about correlating hashes in password dumps here. What are you talking about? > 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. No, this is just gibberish you made up to put in my mouth.
  - rl3 6y ago
    >What are you talking about? The utility of client-side hashing. >No, this is just gibberish you made up to put in my mouth. It was actually a good faith attempt to frame your argument.
    - thaumasiotes 6y ago
      >> What are you talking about? > The utility of client-side hashing. You have responded in the wrong place. Let's start over. pests claimed that performing a client-side salt/hash in addition to a server-side salt/hash has two benefits: P1: User passwords on the server can't be correlated with other passwords in database dumps. P2: Knowing a user's password on the site so protected will not let you learn the user's password on other, third-party websites. But claim P1 is nonsense. It is true that user passwords on the server can't be correlated with other passwords in database dumps. But client-side hashing has nothing to do with that. If the client-side hashing were not performed at all, it would still be impossible to correlate user passwords with other passwords in database dumps. Claim P2 is shaky. It's correct that -- if the method of learning a user's password is to read their active TLS connection with the server -- the password learned by that method will not be useful on other third-party websites. But it does not apply if the attacker's method of learning the user's password was by cracking a password entry in a database dump. The password learned by that method will be whatever the user typed originally, not the hash of it received by the server. What is the value that you perceive in claims P1 and P2? ("Thanks. That was a really clear and concise explanation.") Why are we describing an entirely spurious claim as "clear"?