Trying to do this to distribute the work of creating a lot of users in which their passwords are hashed. This will cause the server to do a very large amount of work. The idea is this:

(Assume encrypted traffic)

==== Creating User ====

  1. Hash password client-side
  2. Send username and hash(+salt) to server
  3. Server saves it directly

=== Signing In ===

  1. Send username and password as text
  2. Verify password server-side. (i.e. hash the plaintext and compare to saved hash)

Is client-side hashing secure during password creation when verification is still done server-side?

  • What your server does depends entirely on how you wrote it/how it works. What you appear to be proposing is a distributed password hashing process, which is parallel to the user password submission process. So, the question is: how have you designed the distributed approach?
    – schroeder
    Commented Nov 19, 2020 at 10:08

1 Answer 1


For transmitting passwords for the first time it would be better to use public key cryptography:

  1. You must derive password (never hash passwords directly) using a strong derivation function like bcrypt or at least a function of the HMAC-SHA* family. Use a random salt, of course.

  2. Encrypt the password using the authentication service public key. It is not necessarily the HTTPS server's public key, ideally it should belong to a server in the back-end (to avoid key compromising in case of front-end server being compromised). Of course, use an existing crypto-suite, do not write it from scratch using RSA primitives (it is very risky).

  3. The back-end server receives data encrypted with its public key. It uses its private key for decrypting it.

  4. Stores the (derived key, salt) pair into the database.

  5. Profit.

Note that in your security scheme, all depends on the password strength against brute-force attacks. Passwords are usually easy to crack.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .