Minimizing the Cost of Credential Loss
Credentials such as keys and passwords, by their nature, are extremely valuable to attackers and difficult to work with securely. Of course we do our best to keep them safe, but what if we fail? Is there anything we can do to soften the blow?
Consider this serious-looking equation:
Cost of Lost Credential == Likelihood of Loss x Value of Lost Credential
The rest of this book addresses the first term—lowering the likelihood of a successful attack. That’s good; that’s where we should focus most of our efforts. But we should prepare for the worst. Let’s assume that some day, despite our best efforts, we lose control of our credentials. Since we can’t 100% guarantee that we’ll never lose credentials, we should take steps ahead of time to lower the cost of the loss by lowering the value of the credentials as much as possible.
We minimize the value of credentials in three main ways:
- We limit the time in which a given credential is valid.
- We limit the power of a user password by splitting authority between a password and a second factor.
- We limit the scope in which a given credential can be used.
Limiting the Time a Credential Is Valid
The simplest way to decrease the value of a credential is to limit the time in which it is valid. No special security knowledge needed, just a bit of deployment savvy.
We get a double return on the effort invested into frequent rotation of credentials. Not only does this help lower the value of our credentials, this is also a capability we need to have in our system anyway. If we ever detect a compromise, we’ll need to rotate all the affected credentials as part of the remediation. Better to have a frequently used, fully automated way to change them than to scramble and learn to do it in the aftermath of a breach. We also need to have the ability to rotate credentials when key members of our team leave the company. After someone leaves, we should rotate all the credentials they had access to.
Credentials used by programs to authenticate to other programs are great candidates for frequent rotation. Programs don’t have problems remembering new credentials. And since programs can’t use two-factor authorization (2FA) as an extra layer of protection around their credentials, it’s good to use frequent rotation as an extra layer of protection.
If credentials never change, then an attacker who steals a credential once has access forever. With frequent credential rotation, an attacker who steals a credential once would either have to make frequent attacks to steal the new credentials or use the initial access to establish persistent access. Both of these make the attack noisier, which hopefully will lead to detection. Additionally, in time, the initial vulnerability may be fixed. Then, once credentials rotate, the attacker is locked out again.
Limiting the Power of a Credential with 2FA
Frequent rotation is great for credentials used by software but problematic for credentials used by people. People can’t remember very many strong passwords and can have trouble remembering new passwords all the time. So when it comes to decreasing the value of passwords used by people, our best bet is to limit their value by splitting authority between a password and a second factor such as a two-factor authentication (2FA) system like YubiKey or Google Authenticator. With 2FA in place, the value of a stolen password is much lower. Additionally, login attempts that don’t have a corresponding 2FA event make for a high-quality signal that an attack is underway. Monitor these if you can. We’ll cover 2FA in more detail in 2FA.
Limiting the Scope of a Credential
Finally, we decrease the value of credentials by decreasing the scope on which they work. Instead of having one superpowerful system account with access to everything, try to have multiple, less-privileged accounts. That way, if one credential is compromised, it doesn’t give over access to everything.
We saw one application of this principle back in Layering Additional Defenses as a Mitigation Against Future Mistakes. We saw that splitting database access across multiple accounts can limit the impact of SQL injection and make attack attempts noisier.
Credentials with limited permissions aren’t just for databases. This same principle can be applied to operating system permissions as well. A typical web application has a web server and a database. Prefer deployments where the database runs as a different user than the web server. Ideally, the database and the web server would be further separated onto different computers. And if there are scheduled tasks, say, in cron, each of them should run as a different user. That way if one of them is compromised, it won’t provide a way for an attacker to move throughout the environment.
Similarly, for user accounts, grant permissions to people on a need-to-use basis only.