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

Question

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?

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.