This is literally impossible to avoid. Whatever the server receives, that's what the password is.
[1]: https://www.cossacklabs.com/files/secure-comparator-paper-re...
EDIT: I mean, yeah, you're right in the sense that whatever you send to the server is used to authenticate you, so that whatever is a 'password' of a sort by definition. However, using the raw password as is for authentication is not a great idea. If you intercept the password, you will be able to compromise any further authentications. There are alternatives that avoid this.
For some reason PAKE schemes aren't that commonly used despite having a solid grounding. Matthew Green has a few good articles on them.
As far as I can see, you do need to send the full password over the wire once when you set its value. But the server doesn't need to remember it.
> For some reason PAKE schemes aren't that commonly used despite having a solid grounding.
It doesn't look like something you can implement unilaterally. How's browser support?
(Interestingly, I guess you could implement it unilaterally between your server and client-side javascript...)
Probably the most common scheme is SRP.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
(Weirdly, the article explicitly notes that s, the salt Carol applies to her own password, is shared with the server and sent over the wire during login. But the salt never appears to be used by the server in any capacity.
And the instruction "Carol must not share x with anybody, and must safely erase it at this step, because it is equivalent to the plaintext password p" doesn't make a lot of sense; presumably Carol isn't going to erase her knowledge of her password -- what does erasing x add?
[The only thing making the password equivalent to x is that the server transmits the value s during the login attempt. If it didn't do that, x would still be useful, but the "password" would be worthless, unless of course s was stored alongside the password...])
>Whatever the server receives, that's what the password is.
I'm not sure what you can do with a "password" that is only valid for a single login and tied to a specific certificate but hey if you want to ride on a technicality I won't stop you. The plain text password that the user types into the input field still remains unknown to the server.
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
Hence why I specified no knowledge of the plaintext password, which is absolutely possible to avoid sending over the wire.
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.
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.
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.
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.
> 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 ), 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.
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-z...
The first two bullet points in that reply are especially salient to this discussion.
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.
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.
> 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"?
I'd say it was the correct place.
>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.
Right—assuming the passwords are gleaned from the database, for example. However, the entire point was that there's no need to do correlation of anything stored server-side in the first place when an attacker is reading the raw user password input as it comes off the wire. Client-side hashing brings this scenario roughly to parity with the protections afforded at the database level.
Database compromise? Server-side salt/hash.
Limited-scope server runtime or network-level compromise? Client-side salt/hash.
Again, it depends on the nature and scope of the exploit.
>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.
Not when you're in possession of the user's non-hashed raw password input. That's correlation city, even in the strict literal sense you're talking here.
>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.
Then you finally cede that client-side hashing has value.
>Why are we describing an entirely spurious claim as "clear"?
I fail to see how it's spurious when we've established countless times throughout this thread that client-side hashing has value.
Do you think client-side hashing has value? Because your original comments seemed to emphatically deny that.
For the multiple machines comment, that is not true. The server can generate a salt/key (or whatever it should be named in this version) and communicate it over the initial request with the login page which is then sent back along with the altered client password, de-salted/unencrypted/turned into something can be compared to the users password. Basically CSRF. You wouldn't need to store these temp salts either if you embedded a timestamp and sign it.
I'm not following you. The system described was:
1. The user comes up with P.
2. The website salts and hashes it, creating C = hash(P,salt_c).
3. C is communicated to the server.
4. The server salts and hashes C, creating S = hash(C,salt_s).
Now, in order to log in, the user must send C, not P, to the server. The goal of this design is that the user does not know C. They do know P. So in order to send C, either the user must remember the original value salt_c, or it must be communicated to them so that they can produce C from P.
We are not contemplating the user personally remembering the value of salt_c, but it would be possible to store it in e.g. javascript local storage. But that would prevent the user from logging in from any device that didn't already have the salt stored. If they cleared their browser history and data, it would prevent them from ever logging in again.
So the server must store salt_c. (As noted above, this means it's now perfectly possible for the server to directly verify that P is the user's "password", the value that hashes to C. But the scheme still allows us to avoid sending P over the wire.) Storing salt_c on the server is the only way to allow the user to log in from more than one browser session.
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.
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.
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.
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.