Consider a strategy for peppering passwords
SamWhited opened this issue · 1 comments
Once #62 is fixed (possibly by #112 being merged), it may be prudent to consider peppering passwords. If the database is compromised, the salt becomes known making brute force attacks against low-entropy passwords much easier. Peppering the password hash involves storing a part of the salt outside of the database, for example in the config file. This way the overall randomness hashed into the password (pepper||salt or similar) will still not be known even if the entire database, or the entire config file (but not both) is compromised.
Because peppers are not unique to individual users like salts are, rotating them presents a problem. In a naive implementation if the pepper is compromised changing it would require that every user in the system reset their password to use the new pepper. This is sometimes overcome by keeping several versions of the pepper in the config file, and storing the number of the pepper, its hash, or some other identifying information in the database next to the password. This way if a pepper is compromised user accounts can be upgraded to use the new pepper on a rolling basis (for example the next time they log in with PLAIN auth, reset their password, or when we decide to invalidate their password and ask them to perform a password reset before logging in again).
NIST SP 800-63b (PDF) effectively recommends using peppers (it recommends keeping salt values secret and storing them away from the hashed password).
Because this is a large(ish?) change that would require some direction from the project leadership, and since I did not know if it would be desired, I did not make it part of #112.
👋 Hi @SamWhited! Done at v0.50.0
To know how to add peppers configuration take a look at this snippet in config example file.
Hope you find it useful, and thanks for all your suggestions (all of them are welcome). 🙇