Client side password hashing

Question

Edit: Updated to put more emphasis on the goal - peace of mind for the user, and not beefing up the security.

After reading through a few discussions here about client side hashing of passwords, I'm still wondering whether it might be OK to use it in a particular situation.

Specifically I would like to have the client - a Java program - hash their password using something like PBKDF2, using as salt a combination of their email address and a constant application-specific chunk of bytes. The idea being that the hash is reproducible for authentication, yet hopefully not vulnerable to reverse-engineering attacks (to discover the literal password) other than brute force if the server data is compromised.

Goal:

The client side hashing is for the peace of mind for the user that their literal password is never being received by the server, even if there is the assurance of hashing it in storage anyway. Another side benefit (or maybe a liability?) is that the hashing cost of an iterated PBKDF2 or similar rests with the client.

The environment characteristics are:

1. All client-server communication is encrypted.
2. Replayed messages are not permitted. ie. the hash sent from the client cannot effectively be used as a password by an eavesdropper.
3. Temp-banning and blacklisting IPs is possible for multiple unsuccessful sign in attempts within a short time frame. This may be per user account, or system wide.

Concerns:

1. "Avoid devising homebaked authentication schemes."
2. The salt is deterministic for each user, even if the hashes produced will be specific to this application because of the (identical) extra bytes thrown into the salt. Is this bad?
3. Authentications on the server end will happen without any significant delay, without the hashing cost. Does this increase vulnerability to distributed brute force authentication attack?
4. Rogue clients can supply a weak hash for their own accounts. Actually, not too worried about this.
5. Should the server rehash the client hashes before storing?

Thoughts?

Answer 1

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database as-is.

On the other hand, hashing on the client side is nice in that it ensures the user that the server has no knowledge of the password - which is useful if the user uses the same password for multiple services (as most users do).

A possible solution for this is hashing both on the client side and on the server side. You can still offload the heavy PBKDF2 operation to the client and do a single hash operation (on the client side PBKDF2 hashed password) on the server side. The PBKDF2 in the client will prevent dictionary attacks and the single hash operation on the server side will prevent using the hashed passwords from a stolen database as is.

Answer 2

There are few time when client-side hashing is worthwhile. One such circumstance is when the hash process is computationally intensive, which can be the case with PBKDF2.

Addressing your concerns:

1. Also avoid unvalidated suggestions about cryptography you find on the internet. (Disclaimer: I am not Bruce Schneier.)
2. Deterministic salts aren't a problem--the only real requirement of the salt is that it is unique for each user. The salt's real purpose is to prevent a brute force on one password from turning into a brute force on all passwords in the case of a compromised database. Even if you were to store a random salt in your database right beside the hashed password you would still reach this goal, provided each users' is different.
3. As I mentioned above, PBKDF2 is nice because you can arbitrarily decide the computational difficulty of the hash. You could select a c such that a single hash on modern hardware takes seconds--effectively eliminating risk of an API level brute force attack. (Of course, your client's might not enjoy such a long delay at login.)
4. An users can choose simple passwords--they are only hurting themselves. If you wanted eliminate this risk, you would have the server generate the hash the first time, provided ithe password is going over an encrypted channel.
5. Yes, and you will need to uniquely salt these as well. In the event of a database compromise, you want to ensure that the attacker doesn't get information that allows him/her to directly authenticate as any user on your system. One caveat here is that you do not want your server-side hashing to be computationally intensive the way your client-side hash is. If your server-side hash takes too much effort, you open yourself to a CPU-exhausting Denial of Service attack vector--an attacker simply spams empty password authentication attempts over Tor, passwords which your server has to try hashing before it knows they are fraudulent, eventually leaving you with an overwhelmed server..

Answer 3

If you hash the password on the client side, whatever the result is IS the password, so you're not gaining any real security. Any hack or information leak that would have revealed the plain text password will instead reveal the hashed password, which is the real password.

This shouldn't be confused with zero-knowledge authentication schemes, where an exchange of messages proves that the client knows the real password, without actually transmitting it.

Answer 4

Hashing on the client can be a good idea in some circumstances and for some reasons, but I would not make "user's peace of mind" one of them. I am all for users to be in an harmonious frame of mind and at one with the Universe, but I find dubious the idea of promoting a way to induce users to reuse the same password on several sites.

A good case for client-side hashing is the way some "password safes" work: they compute a site-specific password by hashing the user's "master password" together with the site name. This gives most of the usability of always using the same password everywhere, while not actually giving your master password to dozens of distinct site. But this works only as long as the password derivation algorithm is generic and not changing; this seems to be much better addressed by a Web browser extension than by an applet coming from the sites themselves (all the sites would have to cooperate so as to use applets which use the same password derivation algorithm, with site-specific data).

Another good case for client-side password hashing is when a slow hash is used (so as to make password cracking harder for an attacker who could grab a copy of the database of hashed passwords); it is tempting to try to offload the cost into the client, since, when the client wants to connect, it is mostly idle and actively interested in connecting. However, slow hashing is an arms race between attacker and defender. Using Java will induce a slowdown (by a typical factor of 3), and some client systems can be quite feeble (e.g. cheap smartphones or ten-years-old computers). This is like picking up a sword instead of an assault rifle before entering a battle where the opponent will bring a tank).

But if what you want, as a user, is to protect your password against sloppy storage procedures by a site, then the right way to do it is to choose a different password for each site. (Personally, I keep a file of passwords, and all my passwords are generated randomly.)

Answer 5

It seems like you're trying to invent your own cryptographic protocol. From the description of your approach, it does not seem like you have the background to do this in a secure manner. I highly recommend using existing protocols instead of creating your own.

First, it's not clear what threat model you think you're circumventing. You cite something called a "reverse-engineering attack" which has no real definition or meaning.

Second, your understanding of a salt's purpose and best practices for its generation appear to be lacking. Salts are not required to be kept secret. You can (and should) generate a unique salt from a CSPRNG for each new authentication token, and not from something like an email address (which might change). Fixed application-specific salts are sometimes called "peppers", and I am unaware of any cryptographic literature which supports or encourages their use.

Third, PBKDF2 is okay, but seriously just use BCrypt. BCrypt was designed for this and is in widespread use. Good BCrypt implementations will handle salt generation and work factor calibration / autodetection for you. You will have to implement these things yourself to use PBKDF2, and you will almost inevitably make mistakes.

Fourth, there is an existing approach to what you appear to be trying to do. Zero-knowledge authentication can be performed with SRP. The user's password is never transmitted over the wire, and a man in the middle cannot sniff anything useful with which to authenticate themselves. However, it is apparently difficult to implement correctly and there are not many existing libraries to do so, which should give you an indication of how difficult the problem actually is.

Long story short: Don't invent your own crypto. Use solutions and protocols that are widely implemented and have withstood the test of time.

Answer 6

A Google employee is working on something similar called TLS-OBC. This RFC draft allows the client to hash the password and bind it to a TLS session.

Specifically you may be interested in this website http://www.browserauth.net/origin-bound-certificates

and this link on Strong User Authentication http://www.browserauth.net/strong-user-authentication

::Update

OBC and possibly the other one is now integrated in the FIDO authentication standard.

Answer 7

Password hashing helps prevent anyone except the user from learning the password. People reuse passwords and they are usually not very strong if memorised. That's why we bother with slow hashes (Bcrypt, Scrypt, Argon2, etc.) instead of a fast hash: it protects the user's password better, even though it does not have any benefit for the application. A secondary benefit of having the server hash an incoming password before storing it in the database, is that someone who compromises the database cannot login with any of the values they found (they first have to crack them).

We want to keep both benefits. To that end, we should hash on the client (slow) and the server (fast).

Why on the server?
Such that an attacker who obtained the database cannot use the obtained data to log in. If your client does a slow hash already, this can be a single round of some secure hashing algorithm (like SHA-3 or BLAKE2).

Why on the client?

1. Transparency
   Whenever a company gets hacked, we have to hope they tell us how the passwords were hashed, if at all. There are still places that store them plaintext, or use a fast algorithm, or don't salt them, etc. By doing hashing client-side, those interested can see how it is done and prevent questions like these. My mom won't be checking it, but my mom also does not check a website's TLS for heartbleed: 'ethical hackers' or white-hat hackers do.

2. Offload the server
   A risk of doing very slow hashes on the server is that an attacker can use it for a denial of service attack: if the server needs 2 seconds to process each login attempt, attackers have a huge advantage in trying to take it down. By doing the slow hash on the client (whose CPU is unused 99% of the time anyway, and it's not as if most people login to something more than a few times per day), you offload the server, allowing you to choose slower hashes without risking an attacker taking down your server.

3. Reduce impact of compromised transmission
   If the secure transmission channel fails for some reason, for example a bug in TLS (June 2020: "Whoops, for the past 10 releases most TLS 1.0–1.2 connection could be passively decrypted"), the impact is lessened because an attacker would only be able to observe the hashes instead of the original password. This also applies when someone is able to decrypt an encrypted stream years later, for example because RC4 is now known to be broken more than a few years ago.
   Note that in the bug from June 2020, authentication does not seem to be affected, so attackers couldn't have modified the JavaScript files to remove the hashing. Now, I have to wonder which passwords I used since the past months over https and if any of those connections might have been passively intercepted.

4. Improve the standard
   Now that we can see everyone's implementation, there will be debate on who got the longest and who got the best. This discussion definitely pressures the bad ones to do better, and it probably also results in standardisation. It would be really neat if you could just add a parameter to the password input element, like <input type=password hash=v1>, which would do all the hashing for you (it would salt with the domain name and username field, but all those details of this proposal are beyond the scope of this answer).

5. Detection of compromise
   A common argument is that "if the server is compromised, attackers could remove the JavaScript code responsible for hashing the password, allowing the attackers to obtain the plaintext anyway". This argument is only valid for websites, but people usually fail to mention that, resulting in that nobody hashes client-side in applications, either. What they additionally forget is that, if client-side hashing is common, security researchers can start using it: there will be people that scan important websites to see if the hashing is still there (it would be quite the indicator of compromise if PayPal removes client-side hashing (in the hypothetical case where they would do client-side hashing in the first place)), and there could be browser extensions (or built-in features) that warn you if it's removed, just like we warn for login forms on http pages.

6. No secret snooping
   Even if they hash the database, employees could intercept the password before it is hashed and stored (by logging at a TLS termination point or by installing some extra code). There are enough stories of sour employees, or even teenagers building some application and want to know what their user's passwords are.

7. No plaintext emails
   If the server does not have your password, they cannot send you email like "Thank you for registering, your username and password are xxx". Email is commonly considered insecure, but there are still websites that do this.

8. No accidental exposure
   There was an incident somewhat recently where passwords were accidentally written to log files. I will not mention the company name because I don't think it's relevant, but it was some big tech company with a dedicated security team and everything. Accidents like these just happen and it had quite a big media fallout. There is additionally exposure in many networks where a separate system does TLS termination and then sends the request plaintext to other systems, allowing any network box to see the passwords (Google used to do this until they got wind of the NSA having intercepts in their internal network). "Plaintext" password intercepts would be less of an issue if we did the hashing before the password hits the network.

9. Why not?
   I cannot think of any reason why you should not do it, assuming you additionally do a quick hash on the server (to get that secondary benefit mentioned in the first paragraph). Even if you think only one of the reasons is compelling, then it would still be an improvement.

---

I think the only reason client-side hashing is not common, is because it's uncommon. Whenever it's proposed, people wonder why it's so rare if there are only benefits. The decision to only do server-side hashing seems to be often rationalized. These are some of the arguments I heard before:

• "An attacker would just remove the code responsible for hashing!" This only applies to web applications. Normal applications (among which mobile applications) do not have this issue.
• "But my case applies to a web application!" If client-side hashing would be common for web applications, we would probably see standardisation (think <input type=password hashversion=1>) similar to how languages and frameworks have standard hashing functions for developers to use. If a field is sent plaintext, the browser could indicate that. We can easily standardise this, but only if developers actually express an intent to do this and we choose to care.
• "But whatever the result [of the client-side hash] is IS the password!" If your login database is compromised, it's unlikely that an attacker still needs to login to your application to grab all the data from it. The defense-in-depth of most systems really is not that good, but even if it is, the argument is void because the advice is to do an additional quick hash on the server.
• "You should just use a password manager instead of relying on the security of hashes!" I agree, that would be ideal. Two factor authentication everywhere, used by everyone, with password managers and smartcards... yeah, when that day comes, we do not need password hashing anymore at all. You should still do a fast hash on the server for the aforementioned secondary benefit, but we can stop doing slow hashing algorithms and client-side hashing because nobody would re-use passwords anyway.
• "You should not put the user in charge of security!" They are already in charge of security: you can always choose to have 123456 as a password (or if there are silly requirements, you can still do "Bailey2009!"). You can also publish the keys to your TLS connection and nullify its security. The user will always be able to mess up any security you implement if they want to.
• "But how will you salt the hash?" The username field, perhaps combined with a domain or company name to make it globally unique. A salt is not secret, only unique, just like your username field.

Answer 8

As one of the users stated "Luc", client side hashing is not common.

Here are the reasons why client side hashing is far more better than clear text which makes them uncommon:

People who are saying that hashing password becomes the password have no idea what they are talking about. This is not the point of hashing a password which they completely fail to realize.

Hashing a password in terms of security point of view is to make it extremely difficult for the hacker to know what the real password is in clear text. So that it can not be used at other websites.

Hashing passwords on client side is not to help protect the server or database, it is to solely protect the user's privacy and credentials.

Hashing passwords on client side also adds many layers of advance protection of user credentials due to advance algorithms implemented by smart tech companies who knows how to implement algorithms which can detect a hashed password from a hacker and from a real user.

One implementation is to have the server distinguish hashed password which was sent that was originally typed as clear text. The server can automatically detect if the hashed password was given by a hacker who did not typed the clear text form of the hashed password. This is not so hard to implement. The benefit of this is that the hacker will now have a difficult time to figure out the clear text form of the hashed password or reverse engineer the server's detection algorithm.

Another implementation is to have the server change it's algorithm of detecting a hashed password that was given by a user in an adaptive manner on a weekly basis. The server's algorithm which talks to the user for a hashed password has now become into an organic organism which will be unique and difficult to understand and reverse engineer by a hacker since the algorithm changes weekly. It's like an organism (algorithm) fighting and preventing viruses (hackers). The hacker will have a difficult time of sending intercepted hashed passwords to the server since they never typed the clear text password to begin with and the server will keep rejecting the hashed password sent by the hacker.

I am not going to get into details of how to exactly to implement it but real professional software engineers will get the idea and can easily implement it. So this is my answer to those people who just says that hashed password is the same as clear text, NO it is not the same in this advanced modern world. They are two different things and advance algorithms can detect many things about a hashed password. Giving hackers full of opportunities to see clear text password is just foolish and dumb. Never rely on TLS "secured" connection, these secured connections can always be easily intercepted by hackers without people being aware of it.

And yes hashed passwords can be run through data crunching machines to know the clear text form of the hashed password but its going to cost them a lot of time and money for hashed passwords that was originally hashed by slow hashing algorithms such as Argon2 which was also peppered and salted by the client.

This is why its just smatter and better to have the client hash their own passwords and send it over to the server.