I had a junior QA discover this while working at a Fortune 50... everything ground to a halt for two days until everyone (team of 20) was assured during a handful of meetings that this is how browsers work and why we use HTTPS.

I appreciate they where trying to protect passwords & promote security, but it definitely caught me off guard that this wasn't widely understood.

> So passwords do get

I think you meant "don't get"

Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes.

There are protocols like SRP to do it securely, but it's non-trivial. And remember that such protocol is only useful if you trust the client implementation—it's kind of pointless for a third-party webpage or app.

Use randomized per-site password. Solves everything.

> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes.

I've yet to see someone give a good reason to not hash on the client and the server... I would be curious to hear if you have any.

It's definitely non-standard though.

Hashing twice, on the client as well as on the server, won't introduce any security issues if the choice of algorithm is good, and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks. (Yes I know MITM means they could rewrite the client to steal passwords, but that's work) If I was designing a password auth scheme that highly prioritized user security, I would hash both client and server side.

>and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks.

It might protect the password if the user is reusing it elsewhere, but it doesn't protect the account the password is securing during the intercepted transmission.

The MITM attacker can just replay the hash.

No reason the server can’t provide a nonce for the login to salt the hash.

Now the server has to store the password in plain text so it can rehash with the new nonce every time.

And how would the server know the desalted hash?

You can't enforce complexity rules or check against known leaked passwords or that they don't reuse username as password or anything like that if you hash on the client too

You can check complexity or username reuse client side. You could even block the n most common passwords clientside if you wanted to.

But I could just ignore/comprimise/modify your client and submit whatever I liked to the server.

What's the motivation of someone able to do that and interested in doing it?

Primarily to get around arbitrary password rules that do not enhance the security of the password but serve to weaken it, e.g. only use special characters from this list: !@#, or sorry your password is TOO LONG (?!)

That's true, but only to a point. You can actually server-side check username/password equality, and a not overly long list of other unwanted passwords. You just have to check each one.

If you hash in the client, attackers with dumped hashed credentials (from elsewhere, which might only hash plaintext) don't need to try to reverse/"crack" the hashes, they can just use them as-is. With users reusing passwords across sites, that would be pretty terrible.

That is why he said, we should do both: hashing client AND server side. Hashing on the client prevents sending plain text passwords to the server which could mishandle them eg. Logging them for instance like Twitter once did. Client side you can also check on registration if the user password is known to have been pwned (1password offers an api for that) and use a secure hashing algorithm. Server side the hash (which is then the password) will be salted and hashed again.

That makes the hash of the user's password equivalent to a plain text password. And that means all those leaked databases, which previously only contained hashes that needed to be bruteforced to be reversed, suddenly function as a source of plaintexts.

I think (s)he is saying to hash client side, salt, then hash again server side. So if the database gets compromised, the attacker still has to apply the salt to brute force the hash.

I can't see a reason why this hurts, but it's probably not worth it. The only benefit I can see it having is if the user reuses their passwords on other sites, as now a potential malicious MITM would have to brute force the client side hashed password in order to reuse it on other sites. They would still be able to use that client side hashed PW to authenticate to the service in question, though.

All the other websites where the users registered using the same email will only hash ONCE though!

Yeah, thats exactly my point. So the MITM who got the PW after client side hash, but before server side salt and hash would have to brute force that hash in order to use it on those other sites. That's the only benefit I see, and a very specific set of circumstances.

Is it incredibly specific? I feel like that happens time and time again when companies accidently "mitm" themselves with logs or whatever.

The first sentence is true (and I can't believe how far down this thread it first appeared), but nobody was advocating abolishing server side hashing as well.

Basically, hashing on the client does absolutely nothing for the security of the transfer or storage of the password. Whatever the client passes to the server, whether it's hashed or not, is effectively their password, and intercepting that (again, whether hashed or not) would give an attacker the actual credentials of the user.

No. The database only contains the double hash. It still needs to be bruteforced.

There is zero downside to doing an extra hash, except the chance that someone codes such a basic thing wrong.

No. Other websites on the internet, where the user also registered with the same email and password, contain the single hash.

Oh, I see. Other websites give you the 'password' to this website.

But only if neither site uses salt, so salt all your hashes. (Not even a salt is necessary here, just a site-wide addition would be fine. Or honestly you could just use a hash that wouldn't be used by a site too dumb to salt their database.)

No - As mentioned in a comment elsewhere, these kinds of experiments fall dangerously into a category of duct-tape crypto.

If you want secure password transfer, do not construct a ghetto solution with stacked hashes, but use a proper protocol like SRP (which, again, is pointless unless the client is trusted).

Especially in the case of Twitter, doing this provides absolutely nothing in respect to credential confidentiality as both sites of the transaction is written by Twitter.

I don't get it. Assuming that a passivly listening attacker has broken TLS, additionally hashing at the client is helpful. The service at hand is now (most likely) insecure, but at least other services do not suffer from the plaintext password being exposed. It's an advantage, albeit small, but it's easy to do with virtually no risk of error.

Stacking hashes is not cryptographically sound. The additional hashing weakens the credentials. Cryptographic hashing is a very fragile subject.

"Assuming an attacker has broken TLS" - this makes no sense. If I had broken TLS, I could send you a login form with no hashing. I could modify your legitimate API requests, without the need for your credentials. I could take your token and forge requests as I wanted. All your assumptions go down the drain, as the security relied on the presence of TLS.

Basically, making this setup is generally harmful, while only providing negligible benefit in a doomsday scenario where all bets are off regardless.

If you truly want to have better security, you need an entirely different system. E.g., local private keys used to sign requests, or a proper password exchange/validation protocol. Smacking another hash on top does nothing good, and the idea is a good example of why normal people shouldn't crypto.

I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation, or if just reasoning simply from e.g. the pigeonhole principle seems to realize the increased likelihood of collisions is negligible for typical hash choices. It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client.

I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...

> I've heard the "additional hashing weakens the credentials" line since I started programming, but no one ever bothers to link a citation

The main issue is that security analysis is non-trivial due to the interaction of their security guarantees. The end-result is effectively a new hashing algorithm. Figuring out the properties of this new algorithm requires a new cryptoanalysis (which is more than just avalanche tests).

> It also flies in the face of common in-practice schemes (pre-bcrypt) like doing n rounds of sha256. There should be no real problem with doing the first round on the client.

Old practices are deprecated for good reason, primarily due to flaws. Looking at what we used to do it not that useful.

The main problem is that it's not just "n rounds". The hash on the client must be salted, and it must be salted uniquely for that credential set, and must use a different salt from the backend hash. Plenty of ways to mess this up, and that's before we're even consider the implementation details of salting.

Then comes the interactions between likely different hashes. All in all, it's pretty complicated.

> I agree with you on the general pointlessness of client hashing, though, and oh what a world if we had pub-priv keys for authentication instead of passwords...

Especially with the only sensible procedure being password managers, it's silly we don't have asymmetric authentication. :(

> The additional hashing weakens the credentials.

If it's true, the attacker just has to do additional hashings to crack the password.

I'd like to highlight that "passively listening" was written intentionally. As soon as an attacker becomes active, he's at an incomparably higher risk of being detected.

If TLS is broken, the world has bigger problems. And then they could simply intercept the session cookie either way.

The session cookie isn’t a potentially reused human-readable string though. The password is.

If TLS was broken, I would always be able to get your password by just removing the hashing from the login page. I'd also be able to modify all legitimate requests, and be able to obtain your genuine login tokens for any site.

That requires an active attack though. Yes, that’s always possible if TLS is broken, but it takes more work and is detectable. (Not saying it’s easy to detect, but it’s detectable in theory, where passive sniffing is not.)

If TLS is broken, you lose all message authentication, rendering tampering entirely undetectable.

Passive sniffing requires the same attack vector, and the idea of an attacker only utilizing passive attacks makes no sense.

The point is that additional hashing designed for the premise of "broken TLS" fails the thread model test: It is pointless, as the only time it is applicable is when everything is fallen apart.

TLS itself doesn't have to be broken to have an interceptor.

If your machine has TLS being intercepted nothing matters anymore. That would be the equivalent of having a keylogger installed. There's no point in trying to protect such a client anymore, it's game over then.

Passive interception happens. Especially when you're using a cipher that isn't forward-secure; a breach of the server could allow it to decrypt previous sessions.

I think the idea is to hash on client _and_ the server. The client 1-way hash (~~unlike the server's 2-way~~) is the new "password" now and it's sole purpose is so that you don't get to see the raw password on the server.

> server's 2-way

Are thinking of encoding / decoding? If so it isn't used for passwords.

indeed, scratch that. i rewrote that comment a couple of times, and that 2-way part is of course not correct. this would defeat the point of hashing passwords if they were reversible

notwithstanding all the other caveats mentioned here, wouldn't hashing on the client side make it possible to salt the hash so that different sites generate a different hash, thus making it unlikely that the hash can be reused even if the actual password is the same? the salt could even include a time component making the hash expire after a time.

this obviously does not eliminate the need for other security measures, so it's possibly more a question of "is it worth it?"

The server would need to hold the unsalted hash then. And if those leak, everything you need to calculate the client salt is right there.

The server should hold the unhashed salt, as is standard. One for client, one for server.

Wouldn't hashing on the client side possibly introduce a reduction in complexity of the password? The hashed password on the client side could be used in place of the plaintext password if the channel is insecure. Lets say the password length limit is 256 ascii chars this is 8*256 bits (ok a little less since not all ascii chars are printable), but if hashed on the client (lets be generous and hash to 1024 bits) it's still half the complexity of the plaintext.

A 128 bit random plaintext is more than secure enough...

If you're trying to argue that the user puts in, say, 60 bits of entropy, and that the hashing algorithm is going to accidentally throw out 10 of those to result in 50 bits of entropy, I believe that any hashing algorithm that did that in a way that anyone can exploit with realistic computing power (a computer smaller than the size of the solar system) would be considered irredeemably broken.

If you are not including humans your maths might be right. With humans not all 8 bits of extended ASCII are realistically used in passwords. And rarely you get passwords longer than 10 characters.

And then: By the password not leaving the system you avoid another issue with humans: If the hash is lost (accidental logging and locks leaking and such things happen) this won't allow to sign in to other accounts, where the lazy human used the same password.

For machine-to-machine communication tokens with higher entropy can and should be used.

It's less about bits and more about entropy. Passwords tend to be low on entropy because of words and patterns present in the sequence. Its almost always going to be harder to break passwords by trying every possible hash than doing dictionary attacks against plaintext passwords. 256 bits is around 37 characters of base64 text. Compare that to most passwords and it's safe to say they aren't losing entropy when hashed.

I'm not understanding this. Couldn't you choose an arbitrary amount of bits to hash to on the client side?

Isn't the main security feature of hashing that you hash against a salt and that no one but the server knows the salt? Once you send the salt to the client (and anything on the client should be considered insecure) you give the ability to generate lookup tables for common passwords. Without the salt it's much harder to brute-force the password.

No. Salts are not intended to be secrets. The expectation is that in the case of a breach that salts are also exposed. What they do is prevent precomputation of lookup tables, granting the developer a bit of time after a breach before all bets are off.

Just use a different salt on the client and server. (and potentially even a different salt for each client)

No, the salt can be public (it was on Unix machines before the invention of /etc/shadow). The important thing is that it is unique per password, so that Hash(Salt#Password) is unique even if two passwords happen to be the same.

1. If the client is written by the same people as the server, then it provides no improvement in password confidentiality.

2. It provides no additional security in the authentication process.

3. It provides no additional security-at-rest for post-breach protection.

Doing something like that ends up in the dangerous bucket of duct-tape crypto. I don't mind people playing with crypto, but things are not as simple as they seem, and "more" is not necessarily better.

The client in this case should be the web-browser; it shouldn't be custom Javascript. There should be an attribute on the password field that says if the password should be hashed before sent to the server. It could also be salted by the browser to reduce reuse across sites similar to any password manager today.

> Hashing in the client leads to a fair share of security issues, especially if it's not also hashed on the backend using the usual salted hashes.

Sure, if you're foolish enough to not hash on the server side then you're setting yourself up for failure. But I fail to see what the problem with hashing on the client side is?

It doesn’t hurt much, but it doesn’t help much either, especially for web applications. If the user cannot trust that the server doesn’t do bad things with the password, they also cannot trust the javascript hash function sent from the same server, so it does not protect against the scenario discussed here. And it is no substitute for an encrypted connection.

No, it does hurt. It also means that you're making up crypto protocols, which is not something you do for fun.

Use SRP or similar if you need private password transfers (which again is still pointless if the client isn't trusted).

Exactly. Using a password manager is probably the most secure thing that can be done these days given your password for the password manager is secure (which it most likely will be due to the stringent complexity requirements for some of these services)

Thanks, corrected :)

Of course it’s OK the authentication system can read the password! What is so wrong on both technical and ethical levels is that the password entered into some data pipeline for machine learning. God knows what else they do with the cleartext passwords.

HTTPS is critical yes. If hash(password) is sent over HTTP in plaintext, then hash(password) can just be used in a replay attack.

You shouldn't be sending passwords in any form over unencrypted HTTP, and there isnt a clear case for hashing or obscuring the password over HTTPS.

Pretty clear case for not hashing however.

Hashing the password on the client limits the password entropy to entropy of hash you generate. Any addition entropy in the original password is thrown away.

Also naive hashing in the client just turns the hash into your password, all of the standard issues of transmitting passwords still exists (such as replay attacks as you mention).

Entropy is defined by the password. The hash is deterministic.

Maximum entropy is defined by the password, the hash can reduce it.

Hashes do reduce it, by an amount determined by the hash size and algorithm.

This has nothing to do with client vs server. SHA1 of STRING will always have the same entropy wherever it is computed; it must, for the hashing to work.

EDIT: I suspect you are confusing PRNGs or KDFs with hashing. Entropy is relevant with the former, not the latter.

As long as the entropy of the client hash and of the server hash is the same, I still fail to see how this is a problem.

AFAIK there isn’t a good reason to do that. To be useful the hash should turn your password into a OTP, at which point it’s no longer a hash

> To be useful the hash should turn your password into a OTP

I'm not clear why you think this would be so. Hashes (with salts) prevent attackers from being able to derive the password, and can also be used in conjunction with nonces to prevent replay attacks.

The point is that you are not achieving much.

You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over. At this point what value are you gaining over just sending the password?

>You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over.

I get the impression you don't understand what the nonce and salt are, so I'll break it down.

The salt is used to make the hashes for particular values unique to this site. It generally does not change across the site, but it makes it impractical to use pre-computed hash tables to find the original values for a given hash. By using a salt, the site ensures that transmitted hashes cannot be trivially reversed.

The nonce is used to allow the use of an HMAC to create a one-time hash that cannot be reused. This would typically be implemented as follows:

1. Service sends NONCE, SALT

2. Client Sends password as SHA256(SHA256(ClientPasswd + SALT) + NONCE)

3. Service Computes SHA256(StoredSaltedHash + NONCE), confirms that it matches what the user sent

4. If the two match, the user is authed.

An attacker cannot reuse what the client sent because the nonce is not reused, and he cannot fake the nonced hash because he does not know either the password or the StoredSaltedHash.

Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, and that can make the hash way less effective in obscuring the passwords if/when leaked.

There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts. There are a bunch of them covering the most frequent passwords. Since you are using the same salt for the whole site, two users with the same password have the same StoredSaltedHash, so you order by number of repetitions, and the most frequent is likely one of those ("123456" tended to be the most popular the last time I checked). This exposes your salt and then it's game over.

What I'm trying to get across (and failing apparently) is that this is still vulnerable to lots of attacks, which means that you'll have to use HTTPS underneath all of this. Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.

>Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password,

This is only an issue if the hash can be reversed. The entire raison d'etre for salts is to prevent hash reversal via precomputed tables.

>There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts

Rainbow tables are already enormous-- in the hundreds of GB range for 9+ character passwords. Iterating over the range of possible salts makes the storage requirements untenable.

As long as you choose an unlikely or unique salt which could simply be your site's FQDN or its MD5 hash, this isn't an issue. No one is going to have a rainbow table for md5(yourFQDN.com) as salt.

>which means that you'll have to use HTTPS underneath all of this

You should but it is not necessary for secure password transmission. This is a solved problem for decades now.

>Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.

Layered security is a thing. Root CAs can be compromised, trusted CA stores can be tampered with, SSL busters like CRIME or BEAST can show up on the scene, someone can gain network access behind the SSL termination.... Layered security is why when LastPass got popped nothing of value was lost, because they used legit KDFs and salts.

There's no increase in attack surface for using an HMAC behind SSL. If SSL is your only line of defense, your security model is stuck in the 2000s.

As a 3rd party who thought he understood this, but then realized he didn't: thank you for explaining it

>then hash(password) can just be used in a replay attack.

If password is sent over HTTP in plaintext, then password can be used in a replay attack.

Of course you can also do a dozen other things with it, such as attack other sites.

And of course this flaw is trivially rectified by having the site send a nonce.

The nonce can be replayed too. Just use HTTPS and (as a user) don't re-use passwords.

If the server sends a nonce and the browser/client responds with hash(password + nonce), a replay attack is not possible.

Yeah, but then the server must know the plaintext password to check the client reply, which is exactly the problem password hashing schemes were designed to solve.

That issue is solved by simply having "hash(password+salt)" the thing the server has stored and is checking.

In other words you can combine salts + hashes + nonces to both eliminate the server's need to know the password and the possibility of a replay attack.

Technically, you should be doing hash(hash(password) + nonce). The server should not know the password, only the password's hash.

That just turns hash(password) into the effective plain text password, which the server must know in this scheme.

Correct. The server should be storing the password hashed as Hash(Password+Salt) to make it impractical for an attacker to recover the user's password.

Recovering whatever the server has stored is typically going to be sufficient to authenticate the user, but storing it as a hash mitigates some threats.

The point of a nonce is that it is onetime, and the point of an HMAC / MAC is that an attacker cannot properly utilize the nonce.

Put plainly, nonces are countermeasures specifically for replay attacks and they work.

Yup. I vaguely recall having to include something like this for a site I built years ago. I didn't code the filter myself, but I remember the feature request that usernames and passwords be filtered based on a profanity list. Users weren't blocked, they would just get "you can't do that" response. The passwords were inspected in memory as part of the request process after HTTPS decryption and before running through the digest function and sent to the DB.

As an alternative to this checkout TozID. The premise of their authentication model is to avoid sending the password all together and use public key crypto to sign and verify requests between the client and the auth server.

https://tozny.com/tozid/

Note that such system only provides you benefit if the client-implementation is to be trusted.

E.g., if your user-agent does it all for you, you could consider it trusted, but if all the code is provided by the "untrusted" service-provider that you won't want to see your password, it ends up just being for show.

Similar situation with ProtonMail: As long as you use the clients shipped by them (webmail, app), all of the security hinges on nothing but a promise. Their app can read the passwords and keys as much as it wants.

Nice, thanks for this!

I also found out that protonmail doesn't seem to send the password in plain text in the post request itself. Really keen to see how they do it as well.

Interesting, but did you really have to be condescending? On top of this, not everyone here is a hacker and not every hacker is a computer security expert.