Application Security — 3 Ways To Protect Secrets
Every development team working on an application will tell you that working with a security team is a hassle, these are also the teams that end up having issues with secrets. Which is why I’d like to explain some patterns you can use as the development team to make life easier for the security team and protect the secrets you are using.
Secret Providers
A common pattern when using secrets is to store them in a remote storage location that can be pulled, this allows you to ensure that secrets are not stored locally on a filesystem. The secrets that are used can be stored in memory within an application, restricting the surface area for an attacker.
Many cloud providers offer some sort of secrets storage that can be accessed via an application user account, when using this type of storage restrict access to only single application user accounts and elevated human user accounts. The benefits of this type of service is by reducing the ability to expose secrets to only the running application and it’s running memory. Don’t don’t copy these secrets locally or store them in an environmental variable within the running environment, as this expands the surface area for an attacker.
Multi-Cred Rotations
During rotation of secrets, there is always a concern that you will lose access to whatever resource you need. A common example is that you have a password for a database and that password need to be rotated, how can you ensure that you don’t lose access to the database during a password rotation?
A common way to handle this is by create two passwords for a database, one that is the “active” password and a “backup” password. This means your code will have to handle two sets of secrets and ensure you are using the one with access to the database, but it also means you can rotate secrets with no downtime. An example of this situation would be an application that is currently running in production, you rotate the active secret “A”, and the application responds by using “B” which is now the active secret. Then you will update the “A” for your application, so it matches your newly created secret which makes it valid. Next rotate your second secret “B” and your application will attempt to use secret “A” which is now the active secret. Finally update the “B” secret for your application making it valid for your database as a backup secret.
This process creates a zero downtime secrets rotation process, which means you can rotate your secrets as frequently as you would like. Making it more difficult to brute force a secret and reducing the time an attacker has to access your applications database.
Secret Print Locking
Every developer needs to be able to debug in their development environment, and while we’d hope they wouldn’t need to use print statements or log secrets during their work. In practice this rarely happens, if someone has the option to do something they will. Which is why Print Locking is important, this is the process of overriding your print statements to scrub secrets, sometimes tying this functionality to a environment.
The reason this works is by abstracting the access from a developer to a library, enforcing a standard feature set around your secrets. This is a common practice in projects that print “REDACTED” or “x*********2” where a secret is either replace by a static string or only the first and last character of a string are printed. Think of these as protecting your logs from exposing secrets to an attacker who happens to gain access to your logging pipeline or logging system.
The preferred way to clear secrets depends on the length of your secret and the type of characters you are using. A good example would be something like this calculator from Tulane University. Given a common string secret with a length of 10 characters, you can expect ~128 days of protection. If you expose the beginning and ending character of your string in your Print locking, expect this to be reduced to ~0.19 days. Always double check the length of the string you are printing and ensure you aren’t reducing the security of the string by using a print locker that shows the front and end of your secret.
If you’re enjoying these articles please let me know what you think and leave me a comment about what you would like to see in the future.
