Suppose one plans to implement authentication for their web app. There have been cases, like with Instagram, where passwords were accidentally stored in plain text due to logs.

While we'd hope to never make this mistake, we're thinking it might be best to do an unsalted SHA512 hash on the client-side, and use that as the effective password to hash again with bcrypt on the server-side?

This way, if a similar mistake were to be made, at the very least the user's original plain text password would never leave their machine. As a result, it can't be stored in our systems.

This assumes that on server-side, we still use bcrypt to salt and hash the password, and store the effective password securely.

The motivation is that in the scenario that a misconfiguration occurs, an unsalted SHA512 string is stored instead of the user's original plain text password. This is still bad, but in theory, less so?

Is this a viable setup, and are the examples of services doing this?

1 Answer 1


While I hope never to make the mistake, is it viable to do an unsalted hash on the front end and send that to the back end instead? Should the same or similar mistake ever be made, at the very least it's not a plain-text password as the real password was never even sent in the first place, but the back end will still use bcrypt to salt, hash, and store the password securely?

Yes, you can do that. However, it will not earn much in terms of security. Why? Because it just means that as far as the attacker is concerned, the hash that client sends is the password.

That is, if somehow the database is leaked, the attacker does not have to figure out the original plain text password, instead it only has to figure out the hash that was send to the server. Why? Because when attacker modifies the front end or creates a rogue client to attack the server, it will simply send the hashes instead of passwords.

For abstract, the attacker does not need the original plain text password at all.

While I understand an unsalted hash isn't particular strong, if in the scenario of a mis-configuration which does somehow log or by any other means store the unhashed password, at least a SHA512 hashed password is stored rather than a plain-text password?

Yeah, and that is all that the attacker needs. Edit: well, that, and to mess a little with the client side code. Since we are assuming HTTPS, I'll assume we are on a browser, so that messing with the client side code entails using the developer tools of the browser.

There are some situations where it could make sense to do cryptography on the client side, this is not one.

The only thing that you arguably won is that the attacker who already successful stole the hash and was able to compromise the account of a user, probably won't be able to reuse it to enter other services where the user has an account...

... I repeat, once everything was screwed, perhaps you earn a little something...

... As you would know, this is not a correct solution for that problem. Which is evidenced by the fact that if everybody did the same client side hash thing, then the attacker would be able to reuse those hashes.

Thus, if the user has different passwords for different services, you approach earns nothing.

Addendum: What if you wanted to defend the user from the administrators?

Note: I will be using the word "protected" to mean that some form of cryptography was used to cipher it.

We often talk about a database being stolen or otherwise compromised. Meanwhile an administrator could just get in and change the stored hash for a user, and get access that way. It could be reverted before the user gets back. And with full privileges that could be done without trace.

There is also the code. The password was at some moment in plain text in the server before being hashed. Depending on the platform, it could be easy to inject some code to steal the passwords there.

And besides all of that, the administrator have access to the rest of the data about the users anyway.

Here is a way...

On account creation (on the client):

  1. Generate an asymmetric key pair.
  2. Derive a key from the password for symmetric cryptography.
  3. Cipher the private key (from step 1) with the symmetric key (from step 2)
  4. Send to the server the public key (from step 1), and the protected private key (from step 3).

On log in (on the client):

  1. Derive the key from the password again.
  2. Get the protected private key from the server.
  3. Decipher the key (from step 2) with the derived key (from step 1)

This means that the server can cipher messages to be read only by that user. Furthermore, if these messages are created on another client, they were never in plain text on the server. The administrators would not be able to read them, because the private key is protected under a key that was never on the server either.

We can add a second, or even more symmetric keys protected under the asymmetric one for performance, we could also use a protocol for perfect forward secrecy. See also Diffie-Hellman. I'm keeping it simple here.

You may consider combining this with a traditional login system, however you should not send the password in plain, because if you do, then it would be possible to derive the same symmetric key on the server. Here, doing a hash on the password before sending it could be useful.

However, that it could be tricky to show that the combination of hash and key derivation algorithm is secure when used this way. Edit: stick to the recommended algorithms at the time.

There is an alternative: challenge based authentication. If the client has the private key, then the client can sign a message in such way that it can be verified by the public key that the server has. In this case, to authenticate the server would send a random text challenge to be signed, and the server verifies that the client did sign with a key matching the public key stored on the server. This way, the password was never on the server at all.

Note: for the above authentication method to be secure I am assuming it happens over HTTPS.

Stolen database? As far as passwords are concerned, there are no passwords there, they never were there.

This has a few drawbacks:

  • Many systems need the data in clear to work, meaning you would hardly be able to put all the data under a key.
  • It is slow for the user, as a lot of cryptography is happening client side.
  • If the user forgot their password, the access to the private key is lost too. The server can let you set a new password, and even a generate a new key pair, but it will not be able to access data that was protected under the old key.

Does somebody use this?

Yes: Famously MEGA.nz does basically this. WhatsApp does something very similar (except they do not store the messages, you do). Other similar products that feature “End-to-end encryption” have similar solutions.

  • 2
    That very small win was the thing I was hoping from this. My scenario where I mess up, log the passwords, and now my system admin can see them, and decided to "have fun" or dump them. While I agree with you that hash becomes their effective password, it was intended to reduce the reusability of it to other services the user may use by storing it differently if they reused passwords. - Very specific scenario... Very small beneficiaries I'll admit. - Overall can I verify, so it sounds like you're saying it's better to not bother and advocate unique passwords, or a password manager?
    – Seth Falco
    Aug 26, 2019 at 2:11
  • 2
    @Seth yes, I would advocate for unique passwords, at least for anything that has any sensible information, regardless of anything else. For any given organization there is virtually no incentive to try to protect the account of the user on other platforms or services after their own was compromised, I would argue that it is better for any given organization to expend the extra effort in making sure they do not get compromised. However, I will expand my answer, I think there is something else we can talk about here.
    – Theraot
    Aug 26, 2019 at 3:08
  • 1
    @Seth expanded my answer.
    – Theraot
    Aug 26, 2019 at 3:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.