Why is it not standard practice to run password-based KDF's client-side?

Question

In most protocols I have encountered in which a passphrase is used for authentication it is stored not in plaintext, but a PBKDF digest of it instead. This is obviously good.

However what does not seem to be standard practice is to compute this PBKDF digest on the client-side while registering/updating a passphrase. Instead, it is often sent to the server and then the user is left to only hope they handle it properly.

Why is this so? Am I missing something?

---

EDIT: Because this was unclear to some, I don't mean to suggest the server-side should not hash. The server should. I'm asking why it's common practice to not hash client-side at all.

Answer 1

I think the main issue are the client side languages (normally JavaScript), they are relatively slow. This would often lead to fewer hashing rounds and therefore weakens security.

If your client side language is fast enough, you could calculate the expensive PBKDF client side, then calculate a cheap hash on server side (SHA512 for example). To get the plaintext passwords an attacker still had to calculate the slow PBKDF. It is also not possible to use the PBKDF directly as password, because only the hash of the PBKDF is stored (the output of a PBKDF2 can be seen as a very strong "password", so it is safe to use a cheap hash function).

One downside is, that the handling will become more complex, you need to send salt and cost factor to the client for verification of the entered password. Another problem is to ensure integrity of the client side code, if somebody could alter the delivered JavaScript code, he could return a known string and you would store the now unsafe PBKDF.

Answer 2

Look at it from two extremes:-

1. Server is using PBKDF properly

   If the server is doing PBKDF properly, it would be a useless duplication of effort and resources if you do the same thing on the client-side too. You will have to implement or use a client-side software that will run PBKDF on your password and then send that to the server, and the server will then run PBKDF on the out-put of the client-side PBKDF and store that in its database. I hope you can see the use of the additional resources without any additional benefit.

2. Server is not using PBKDF at all

   So if the server is storing passwords in plaintext, the output of your client-side PBKDF will be stored as it is on the server. So when an attacker steals the server database, it won't make a difference if your password was PBKDFed on the client-side, to the server (and the attacker) it will be exactly same as a plaintext password like hunter1 :)

So to answer your why, the general principal is that its the entity that is controling the resource that is responsible for its security, which in this case is access control. Or as a saying in my mother language, "the thirsty man has to go to the well, the well doesn't come to the thirsty" :)

Answer 3

I realized that this was brought up long ago, but here's my take anyways. If KDF processing is done on server side, then the sysadmin of the server is to be considered within the adversary model, as he/she could manage to somehow sniff process memory and learn clear text user passwords. In my eyes, this scenario (malicious sysadmin after some sort of impersonation attack) might be more common/feasible than the one when the attacker grabs a copy of the authentication database of KDF processed credentials. Just my two cents.

Answer 4

A bit of background first:

The reason why passwords are not stored as plain text usually is to provide defence in depth. That is, in the case of a database compromise (which is something that should obviously be prevented), it should prevent the attacker from gaining access to the original user passwords. This usually makes gaining access to the PBKDF2 secured passwords less valuable to the attacker. Of course, this only holds true when the passwords are strong themselves.

---

To answer your question:

If the PBKDF2 were computed on the client-side, then once the attacker gains access to the database, the attacker can make use of the PBKDF2 output (stored in the database) to login as the victim users through the web interface. That is, the attacker does not need to gain access to the original password to login. The attacker can simply send the username and PBKDF2 value of the unknown password to the server and get logged in just like a legitimate user. The only difference is that the legitimate user makes use of JavaScript or some other client-side mechanism to compute the PBKDF2 value while the attacker would have it in the database.

As a result, the original premise of making gaining access to the hashed passwords less valuable does not hold any more since access to that information does have value (gives the attacker access to the victim users account). It has less value to the attacker than gaining access to the original password (before performing the PBKDF2 operation) but has more value than if it were encrypted on the server-side.

There are other problems with client-side PBKDF2 that I think should be mentioned:

• a static salt would have to be used (i.e. it cannot be random as it would produce a different PBKDF2 value)
• other values passed to the client-side PBKDF2 client-side function would also need to be static, thus removing a number of security features (such as changing the number of iterations)
• just like in the case of server-side PBKDF2, the original password can be retrieved by injecting JavaScript code to read keystokes or input values in the case of a web application compromise (e.g. XSS and various other vectors); so that the potential security gains of client-side PBKDF2 there are lost