4 ms·

>This is literally impossible to avoid. Whatever the server receives, that's what the password is. Hence why I specified no knowledge of the plaintext password

by rl3 6y ago

>This is literally impossible to avoid. Whatever the server receives, that's what the password is. Hence why I specified no knowledge of the plaintext password, which is absolutely possible to avoid sending over the wire.

thaumasiotes 6y ago
Sure, if you've implemented SRP as suggested sidethread, you don't need to send the password over the wire when logging in. But you're not talking about that. You, rl3, are just misunderstanding what a password is. If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2, and send 200820e3227815ed1756a6b531e7e0d2 to the server, then the user's plaintext password is 200820e3227815ed1756a6b531e7e0d2.
- 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.
- rl3 6y ago
  >You, rl3, are just misunderstanding what a password is. On the contrary. I also suggest sparing the theatrics next time. >... then the user's plaintext password is 200820e3227815ed1756a6b531e7e0d2. "In cryptography, plaintext usually means unencrypted information pending input into cryptographic algorithms, usually encryption algorithms." [0] Or in this case, cryptographic hash functions. [0] https://en.wikipedia.org/wiki/Plaintext https://en.wikipedia.org/wiki/Plaintext
  - thaumasiotes 6y ago
    Yes, and, in the example I gave, 200820e3227815ed1756a6b531e7e0d2 is unencrypted information pending input into a hash algorithm. Plaintext.
    - rl3 6y ago
      >If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2 ... By your own words it's already been run through one hash algorithm. Even considering it's being hashed again on the server, that still isn't plaintext. The plaintext here is qwe123, because that's the raw user input. If it avoids further pedantry, we can agree to call it cleartext if you prefer.
      - thaumasiotes 6y ago
        A hash algorithm is not a supernatural function which changes the metaphysical character of data. Whether something is plaintext or ciphertext depends on what you're doing with it. And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. All the server does is run a hash function and record the result. That result is the ciphertext, and the input is the plaintext, no matter how the input was generated.
        rl3 6y ago
        >A hash algorithm is not a supernatural function which changes the metaphysical character of data. Again with the condescension. >And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. Except they're not, because the former is presumed to be salted client-side, and it is not always true that the attackers [who have compromised the server in some manner] will end up knowing that salt. There are innumerable schemes that can render gaining knowledge of the salt difficult if not impossible, especially in the case of a server exploit that's limited in scope.

by rl3 6y ago

thaumasiotes 6y ago

Sure, if you've implemented SRP as suggested sidethread, you don't need to send the password over the wire when logging in. But you're not talking about that. You, rl3, are just misunderstanding what a password is. If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2, and send 200820e3227815ed1756a6b531e7e0d2 to the server, then the user's plaintext password is 200820e3227815ed1756a6b531e7e0d2.

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.
rl3 6y ago
>You, rl3, are just misunderstanding what a password is. On the contrary. I also suggest sparing the theatrics next time. >... then the user's plaintext password is 200820e3227815ed1756a6b531e7e0d2. "In cryptography, plaintext usually means unencrypted information pending input into cryptographic algorithms, usually encryption algorithms." [0] Or in this case, cryptographic hash functions. [0] https://en.wikipedia.org/wiki/Plaintext https://en.wikipedia.org/wiki/Plaintext
- thaumasiotes 6y ago
  Yes, and, in the example I gave, 200820e3227815ed1756a6b531e7e0d2 is unencrypted information pending input into a hash algorithm. Plaintext.
  - rl3 6y ago
    >If the user types qwe123 to log in, and you hash that in Javascript to 200820e3227815ed1756a6b531e7e0d2 ... By your own words it's already been run through one hash algorithm. Even considering it's being hashed again on the server, that still isn't plaintext. The plaintext here is qwe123, because that's the raw user input. If it avoids further pedantry, we can agree to call it cleartext if you prefer.
    - thaumasiotes 6y ago
      A hash algorithm is not a supernatural function which changes the metaphysical character of data. Whether something is plaintext or ciphertext depends on what you're doing with it. And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. All the server does is run a hash function and record the result. That result is the ciphertext, and the input is the plaintext, no matter how the input was generated.
      - rl3 6y ago
        >A hash algorithm is not a supernatural function which changes the metaphysical character of data. Again with the condescension. >And to the server in this example, 200820e3227815ed1756a6b531e7e0d2 and qwe123 are exactly equivalent strings. Except they're not, because the former is presumed to be salted client-side, and it is not always true that the attackers [who have compromised the server in some manner] will end up knowing that salt. There are innumerable schemes that can render gaining knowledge of the salt difficult if not impossible, especially in the case of a server exploit that's limited in scope.