Earlier this week I approached Guy Peer, one of Dyadic’s co-founders and VP R&D and asked him – as a developer, someone who’s been doing this for many years, can you explain why developers so often place passwords in plaintext in configuration files and in code. The answer was short and simple – storing credentials in cleartext in config files and code is the easy thing to do, what else do you want to know?
I asked him to be more specific. Understanding the leading causes is the first step towards figuring out the right way to approach the problem and solve it.
Below are five reasons and bad habits that lead to one of the biggest security exposures there are, and one of the best methods hackers have for propagating attacks in the organization.
- It is the default Whenever you install a software piece required for development, whether it is a database, web server or other, you usually look and find for all settings in some settings file, these settings would usually include passwords and other sensitive data as well. Of-course, somewhere in the module documentation there is a warning to avoid use clear text passwords in production environments, but how often such documents are being actually read during development?
- This is how it appears in code samples With the vast spread of open source components and coding communities, much of the code you would find in applications today, specifically when it comes to connecting with 3rd parties, is something pasted from a code sample. Whether it is stackoverflow, pastebin, or the 3rd party vendor itself, the sample would always be simple and self-contained, typically keeping passwords in plain. When the code is copied, the easiest approach is to keep it as is (a more responsible programmer would change the default password… but that’s about it).
- It is easier to share Assuming you like to protect sensitive information using techniques such as encryption, you are now required to provide all programmers, QA testers, support personnel, integration lab, etc. the encryption key, so they can run the software. This is a synchronization nightmare, and with top priority being having the system running at all times, such solutions are often not being used to avoid the risk.
- It simplifies installation. One of the strongest drives when creating an installation package or building a deployment scheme is to reduce environment dependencies and being able to replicate exactly the same configuration over and over again. Having all passwords encapsulated in code or plain text files, allows exactly that. While encryption or locally ciphered files, would make each instance unique with dependency in the local environment.
- It’s very hard to track misuse The bigger your application and development team gets, the more you will find yourself using external resources. How can you enforce proper usage of passwords and other credentials? Proper usage of credentials, as long as there is no simple and usable tool for handling it, becomes almost impossible.
So this is what we’re facing when we want to secure these credentials. And the only way to address these causes is by providing ongoing security education and awareness, as well as supplying developers with an easy and accessible way to secure them without wasting too much time or struggling with it disrupting work.