Where to store a pepper?

Question

Assuming you're using a pepper in your password hashing, where should it be stored? I know you shouldn't store it in the database since it can easily be found there during a dump and the idea is to have something stored outside the database, but can't you make a similar case for storing it in your source code? My instinct would be to store it on a different place than where your code and your hashes are, so that an attacker who compromises both of those has less chance of compromising the pepper as well.

My first thoughts on where to store it:

Windows

• In the registry;
• Using DPAPI;

Linux

• ??? (I'm not familiar with Linux systems)

Cross-platform

• on an external server, presumably as a consumable service that receives a password and returns a hash;
• on special hardware like a security peripheral or a secure enclave that works similar as the external server.

You could probably come up with a reason for every one of these methods, as well as a reason against each of them. Where do you store the pepper?

Answer 1

If you have a HSM then the pepper should be in that HSM, because that's the whole point of having a HSM.

Otherwise, the pepper is a key which should be handled as such. Having a key involves key management; it should not (and, really, must not) be hardcoded in the source. The source code is copied in multiple places: developer's machine, versioning systems, many backups... The key really is a property of the server instance (lone server or set of servers that use the same set of registered users) while the source is, conceptually, shared between many server instances.

On Windows, the DPAPI is what will make auditors most happy, although one may say that the extra protection offered by DPAPI is not, in fact, that big. If you reboot your server, it starts automatically; this means that regardless of where you put the pepper, the cold storage of the server (harddisk contents) is enough to recover the pepper. The pepper is meant to resist partial read accesses by attackers (which is why you do not put it in the database), but if the attacker can read the registry, then he has a lot of control over the machine and probably won't be much hindered by DPAPI either. If you use the registry, adjust access rights on that specific key so that only relevant users may read it (typically, the user account under which the server runs).

Using a file incurs the risk of read access through a poorly developed script that ends up dumping contents of attacker-chosen files.

On Linux there is no registry and no DPAPI, so use a configuration file. A case could be made of running the pepper processing in a distinct process accessed through some inter-process communication mechanism (say, Unix-level sockets), and run the actual server code in a chroot.

---

In all cases, using a pepper has its own costs: you have a key to manage, i.e. to generate securely, and keep safe. If you lose that key, then you lose the ability to verify user passwords, which can be very inconvenient. In that sense, the pepper is more critical than the server private key for its SSL certificate.

Answer 2

In my preferred order

1. In a hardware security module (DIY or cheap options)

2. In a smart card attached to the web server (will probably be slow)

3. In a computer connected to the web server with a very, very simple API that can calculate the HMACs for you but won't give up the key

4. In a file on the web server that can only be read by the web server process