Storing Passwords When You’re the Client

So now we have four perfectly good password-hashing algorithms we can use. They’re so good it’s tempting to think that we’ve solved password storage for all use cases. Unfortunately, that’s not the case. We can only use these for hashing the passwords of clients that authenticate to us. If we need to authenticate to another system, we can’t use these password-hashing algorithms because they’re one-way only. We can never get the passwords back from a hash. So we’ll need another approach for storing passwords that we need to present to other systems.

Storing passwords on servers

How should we store passwords that are used by our servers to connect to other servers? Perhaps we could encrypt them before we store them on disk. That sounds good, but it doesn’t buy us much. The problem is that the decryption key has to be available in the clear so that our application can decrypt the password in the config file at run time. So how do we protect that decryption key? Eventually, our applications need to have access to credentials in the clear.

The applications we build need to have access to the secrets they require in the clear. Whenever possible, we should run each application on a dedicated server running as a dedicated service account. For example, use separate accounts for your web server and database server, and only give the database account access to the database server.

If we can’t manage to put each application on a dedicated server, our only other option is to leverage OS permissions. We can use a separate OS account for each application that runs on a given server. This isn’t a very strong defense because operating system privilege escalation vulnerabilities are discovered all the time. We should consider a compromise of any account on a server to compromise the entire server. But in situations where multiple applications have to run on a single server, this can at least be a speed bump that slows down an attacker.

It can be worthwhile to use a key store like Azure Key Vault, AWS Key Management Service, or HashiCorp Vault. They don’t keep your secrets safer than not using them, since a compromise of a client of one of these key stores will result in compromised keys, just as would be the case if there were no key store in place. What the key stores provide is an audit trail of key access and key rotation. So by using these, you’ll have an easier time determining which hosts accessed which keys and when. You’ll also have a way to keep track of how often the keys have been rotated.

Storing passwords on workstations

When it comes to passwords on workstations that you use to authenticate to other systems, use a password manager such as 1Password. The biggest benefit of this is that you’ll be able to use a separate password for every website you log into. This helps you because if one of the websites you use is compromised, the attackers won’t be able to use your password from one website to give them access to other websites. The next benefit is that you’ll be able to generate long passwords drawn from large alphabets. Password managers have fancy additional features like cloud-based sharing between devices. Only use these kinds of features if you must. Better to type them in by hand if you only have a couple of passwords to share between devices. Password managers also have fancy browser plugins to streamline the pasting of passwords into login forms. It’s better to not enable these and instead just copy and paste from 1Password. These plugins increase your attack surface but don’t add very much usability.

                                                 Q U I Z