Sending passwords plaintext over the wire isn't good either, even with TLS. You don't want your server to have any knowledge of the plaintext password. For that reason, it's a good idea to salt and hash passwords client-side as well.
An even better idea is to not roll your own authentication if you can help it.
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.
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.
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.
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.
TLS is quite strong, and if your adversary has broken your TLS then they can also intercept cookies or inject code to capture the plain text.
(The threat model has to involve an accident, because if the user wants to know his password, he can just look at it when he logs in.)
The strategy is called "passing the hash", and it will be flagged as a low-priority problem if you get a security review. It doesn't introduce a weakness, but it's a sign that you don't know what you're doing.
(The more classical form is that you _only_ do the hashing on the client side, in which case you've also introduced the issue that your database stores everyone's password in plaintext.)
Incorrect. Please refer to other comments in reply to you.[0][1]
>It doesn't introduce a weakness, but it's a sign that you don't know what you're doing.
How's the old proverb go? "Those who live in glass houses should not throw stones"
Connected with password reuse across different websites, this could present a problem for the end user.
Pretty much this. If you’re stealing a password in transit, you can just steal the auth token instead, and that attack would bypass MFA. If you compromise the server, you’re well past caring about the individual passwords anyway because you can just serve a version of the client code that doesn’t hash on the client side. If you’re phishing the user, it doesn’t matter what the client normally does because the fake login probably isn’t going through your code. If you’re trying to safeguard against CSRF or a related attack, again either the client code got injected or they’re just using your auth token and don’t care about your password
You could salt and hash again on the server side, but its benefits are marginal. But if you don’t salt and hash on the server side, because you did it on the client side, then you have a known vulnerability (“pass the hash”).
What if the client files are delivered via CDN, and the server in this case is an API?
Don’t forget about the main point: hashing and salting on the client side does not replace doing the same thing on the server side.
Per my original, top-level comment:
"For that reason, it's a good idea to salt and hash passwords client-side as well." [emphasis.. nevermind.]
If your server is compromised, you don't want it handling plaintext/raw password input from your users.
This doesn't work; see the other line of the comment you're responding to:
>> if your adversary has broken your TLS then they can also intercept cookies or inject code to capture the plain text
You're assuming that the attacker controls the connection with the user. Such an attacker is free to serve a login page that sends the unhashed password, and read that.
I am making no such assumptions.
>Such an attacker is free to serve a login page that sends the unhashed password, and read that.
Depending on the nature of the server exploit, and depending on if the client code is even delivered via the same server handling requests in the first place. Both are quite large assumption to make.