Hacker News Reader

Comment by UnicycleSkewer | Hacker News Reader

I wonder why it isn't best practice to hash with a salt and then encrypt the passwords using something like AES. The encryption key can be stored in the secrets manager and be injected via environment variables.

Unlike a pepper it is possible to change the encryption key if it is leaked. I don't think changing a pepper for existing hashes is possible, but if they are encrypted you can just reencrypt them with the new key.

So is there an obvious downside I'm not seeing to hash with a salt and then encrypt?

View on HN

It's possible to change the pepper during login (same as adjusting parameters).

The downside for the scheme is complexity and limited upside; complexity gets a lot more attention when it comes to security considerations.

Best practice especially needs to be simple; it's easy to mess this stuff up and hard to understand. A lot of the comments on this post betray a very poor understanding of password storage; they simply haven't come across the correct information.

Overall pepper is good as long as you include salt. There are times when the db gets leaked and the env variables don't.

There's nothing wrong with your scheme if it's implemented properly, but being able to change the site-wide key is a limited upside compared to using a pepper. There is an upside though.

And all of this doesn't matter much as long as you do the bare minimum of using a tuned pbkdf+salt and keep your stuff patched.

I don't see any downsides. As you point out, upgrading hashed peppers isn't as beautiful. Yes, you can just introduce a new pepper and wrap the old hash into another hash using the new pepper, but you'll still have to keep the older pepper around to obtain the old hash during checks, creating risks if the attacker gets access to the older pepper and an old db backup. With AES usage, you can throw the old key away once all of your db has migrated and you've updated your key backups.

Just make sure you use a suiting AES mode. If it turns out that you xor'd all hashes with the same stream that depends on your pepper only, it's not really helpful :).

I can only think of two things, and they're manageable.

One, slightly longer password checks. And two, the temptation to lean on the AES key and set the cost of the hash too low. In the case the key does get out - we had an entire era where people stole environment variables from servers - then you decrypt the entire password file once and have cheaper guesses per second.

The only downside I think of is that it's not possible to recover from an outage with just the code and a database backup.

I guess that is true, but if you store the encryption key in a secret store on Azure or AWS, I wouldn't really worry about that.

Maybe the real question is why use a pepper over encryption?

They have the same downside (as you mentioned) but at least you can change the encryption key without having all the users change passwords. I don't see any advantage in using a pepper over encryption, except maybe implementation complexity.

Pepper, encryption, they both guard against drive-bys, which can happen for sure (missing backups anyone?) but they're not the only thing that can happen.

Like any disaster preparedness situation, make sure your strategy doesn't count on an asset you've already listed as unavailable.

Reply on news.ycombinator.com