How to make the first request which used to create account safe?

Question

To authorize user, our application defined below steps:

1. Send user email and password (plain text) through HTTPS.
2. When server received it, generate a salt to hash password and store it.
3. When user wants to login, verify password with salt.

For revoking an user password easier, I choose to generate a salt on server. But my workmate thinks password should be hashed on client before it sends to server.

My question is if we hash password on client, it will make password more secure. But we still transmit salt to server or we can't verity it. If anyone get this salt, the password is still insecure. How can I protect this request?

Answer 1

Client-side hashing can be combined with server-side hashing if you want, but server-side hashing (using a slow, salted hash, typically one of - in descending order of strength/modernity) argon2, scrypt, bcrypt, or PBKDF2 - is essential. You can re-hash something that was already hashed on the client. However, if you were to just take the hashed password from the client and use it directly, not only would the hash probably not be as good (it's complicated to handle giving a user the right salt securely, among other problems), but the hash itself becomes password-equivalent; an attacker wouldn't even need to know what the original password was, if they captured the hash (either from the network, if you messed up your TLS somehow, or - more likely - just out of your auth database) they could just send it to the server and log in as the user.

It sounds like you're trying to roll your own authentication system without much understanding of the security risks around authentication. Is there some reason you can't just use an existing library? Many of them aren't great, but if you were seriously considering either only-client-side hashing or believe that a password passed over HTTPS is "insecure" in any way that a salt helps with, then almost any well-established auth framework will (no offense intended) be better than you would create. Don't re-invent the wheel without reason.

Answer 2

The sole purpose of a salt is to increase the difficulty of brute forcing multiple passwords by preventing someone who obtained a list of N hashes of attacking all N hashes in parallel (or combining work of prior attacks).

If an attacker can inject javascript and change the salt used sent along with the password, they could also inject javascript to just directly observe the password that you typed into the browser.

HTTPS is encrypts network traffic. In the normal workflow, where you send the plaintext password over HTTPS, the server takes the received password, hashes it in a strong manner (with a salt and many rounds of hashing; like sha512crypt or bcrypt), no network eavesdropper can intercept the password. Yes, a vulnerability in the client side javascript or the server-side code could take the plain text password. However, a vulnerability in the server-side code could insert malicious (minified) client-side javascript to get the password directly.

Answer 3

The purpose of salting is to increase the effort required in brute force by a significant amount without increasing load on the end user. It also helps in combating the use of hash tables and rainbow tables for password cracking. Salt should never be reused because if salt is fixed then a new rainbow table can be generated using the salt.

Since the connection is over HTTPS, the only disadvantage of submitting the original password to the server is the risk of it getting leaked in logs. If logging is done properly with no traces of plaintext password then there is nothing to worry and most of the sites (Google, facebook, twitter, etc.) submit your original password on their servers and then hash it before storing.

Even if your database is compromised and all the salts are leaked, they'd be of no help if each salt is unique and generated randomly. So both of the options provide almost the same level of security with the only advantage in generating hash on the browser being the avoidance of password leak via server logs.

If you're talking about salt getting compromised over the network, it won't be possible since the connection is over HTTPS. Make sure your certificate is issued from a valid CA. In case the connection is over HTTP, the salt will be of no additional advantage for an attacker in cracking the password hash.