Hash pepper in web application possible?

Question

I have read a few articles and several question on here about hashing correctly. While hashing, adding salt and especially pepper is primarily a server side use case, I am interested in the possibility to implement (not talking of inventing security mechanisms myself) as much of these practices in a JavaScript based web application (client-sided) additionally to the server side.

Hashing

...as answered by many questions before, is totally possible on the client side but still crucial on the server-side to not replace the hashed password with the client hash itself. Additionally the password is protected in case of a compromised server. An attacker who gets hold of it due to an insecure connection has to use a rainbow table to find out the password instead of clear text.

Salt

...has to be unique but not necessarily more private than the hashed password itself, is stored in the same database. Like-wise a client salt could be the unique user name, however salting is irrelevant to the attacker if the user is send in clear text in addition to the hashed, salted password. (But without the user name, the salt does provide additional security.)

Pepper

...has to be secret, is shared for all passwords in an application and kept separate from the database containing hash and salt (e.g. in the application as the application might not be accessible for an attacker who did an successful SQL injection in the database). If the JavaScript of a web application included a hard coded pepper, the attacker would easily find it out and therefore make the pepper useless.

(Again: assume the server side to hash, salt and pepper no matter of the actions on the client side)

Is there any way to pepper on client side to increase password security while transmition? I have no experience in security and can not think of a way to include such a pepper safely since the attacker can be the client or fetch the server's traffic including the client's pepper.

Answer 1

The use case of a "pepper" is to make it impossible to crack password hashes in the case the attacker has obtained the password hashes but not the pepper value. One such scenario would be limited SQL injection, where the database contents can be read but not the file contents.

One way to provide similar security would be to use asymmetric encryption. The client encrypts his password hash with the public key of the server. The server has the corresponding private key and can decrypt the password hash to verify it. This way, the client can perform the work to make the password hash available only to the server.

Answer 2

There isn't any reason to use salts client-side. Using a salt server-side serves three purposes.

1. It makes it so offline cracking effort spent recovering Alice's password isn't useful for recovering Bob's password. (As long as Alice and Bob have different salts.)
2. It prevents offline cracking techniques that utilize precomputed hashes. (As long as salts are unpredictable.)
3. It prevents someone with a dump of a password-hash database from determining whether two or more accounts use the same password. (As long as salts are unique.)

The client never receives a hash of a user's password. Checking the input against the stored hash is the server's job. If you gave a client a password hash then you are enabling offline cracking.

Salts are a way to make (offline) cracking as many password hashes as possible less easy. They are a layer of defense^*, but they don't eliminate the danger of a password hash getting leaked.

(Leaked hashes allow offline cracking, meaning the server cannot impose rate limits or account lockouts. A server can't protect a user from their password getting cracked. Nor will it be able to tell when or if login credentials have been compromised.)

You're handing passwords wrong if you need to add a salt client-side. Only stored password hashes need to have salts. The exposure of password hashes should be as limited as possible.

_{* Salting does not protect individual accounts from being targeted. It also doesn't help if a cracker needs to compromise only one account; they can target everyone, guessing weak passwords, and successfully hack the account with the weakest password.}

---

As you described it, the "pepper" is just a second salt. It's the same for all users and, if you give it to clients, it's not unpredictable. It adds nothing if it is not secret, so it should not be sent to clients.

Again, if you don't have the password hash then adding "pepper" to input doesn't serve any purpose.

---

One of the alternate definitions of "pepper" simply refers to encrypting password hashes and salts. This would provide total protection against offline cracking, assuming that encryption is done properly and that the key used isn't leaked along with all the password hashes.

This type of pepper is a good idea, but it's not perfect. It really only helps prevent offline cracking if just a copy of the password hashes get leaked. (For example, through SQL injection or, if the key is not stored on the same drive, someone copying the hash database from the server's hard drive.) It doesn't protect against total compromise of the server.

---

Use HTTPS. Clients (browsers) already implement it. It's easier than implementing your own encryption and you want use HTTPS anyways.

No matter what kind of password handling you do client-side, your user sessions will be vulnerable in some other way if communications are not encrypted and authenticated. (Session cookie stealing and man-in-the-middle attacks, for example.)

Plus if the JavaScript being sent to the client or the page that loads the script is not authenticated, then it's possible that the scripts or page can be tampered with in such a way that it defeats whatever client side hashing you do.

Answer 3

The other answers have covered how hashing salting and using a pepper make it difficult to crack passwords. As far as security of user credentials in transit is concerned, HTTPS Everywhere should take care of that.

Let us say an attacker is able to compromise the HTTPS connection and see the application traffic between the web browser and your server. Assuming this is your attack scenario, even if you add another layer of security (client side hashing/encryption), it is relatively easier for an attacker to alter the web pages served to the client's browser and obtain user passwords via phishing, rather than attempting to reverse engineer your client side security mechanism.