Security errors and overmitigation

The last version of the SANS Top 25 is out. This is a list of the top 25 most dangerous security errors committed in programming. It's an interesting read for anyone who cares about security, and if you're like me, you'll recognize in the list some sins from the past perpetrated by yourself.

There is however one that caught my attention. Number 11 is the use of hard coded credentials.

Basically this happens when some program is connecting to a service using a username and password. Usually, those credentials are requested as part of the program operation. But there is a large category of systems where this is not possible. Web servers connecting to database servers and ETL (extract-transform-load) tools or hand coded equivalents are usually run in servers without user intervention. They simply cannot ask for user credentials each time they need it because there is no user to ask for in the case of batch processes or because the service they are providing is accessible for everyone, making this step redundant.

The analysis is at first good. When you want your program to connect to the database without asking for credentials, your program needs to provide those credentials. Plain and simple, your program knows them and there is a risk if someone peeks at the program or configuration file where they are stored. To be more accurate, the risk is proportional to the chances of the place where those credentials are stored being accessible and inspectable by attackers.

What surprises me in this case are the prevention and mitigation measures. Storing them in a separate configuration file is fine, providing you take measures to make this configuration file not accessible for outsiders. Storing them encrypted does not seem to add a sensible amount of protection, as again the decryption keys must be embedded in the program binary or stored elsewhere. Where do you store those, in another encrypted configuration file, perhaps?

True, if the configuration file falls into the wrong hands, your credentials will not be compromised if they are encrypted. But my bet is that if that happens, the place where the encryption keys for the configuration file are stored is also going to be retrieved by the bad guys. You can build layer after layer of encryption, but you'll still be reliant on access protection to not reveal your secret keys.

Rather than add more layers of encryption, it seems better to focus on preventing access to unintended locations in your system.

In fairness, at the end of the section they reckon that none of those preventions and mitigations are complete. You now know why.