Post navigation

Use of hard-coded credentials, a dangerous programming error: CWE

For applications and scripts in your infrastructure that communicate with other applications using a password, the normal practice is to hard-code the password in a configuration file or a script. To explain further, for Application-to-Application or Application-to-Database communication that happen without human intervention, normally organizations define the access permissions in one application (say Application ‘A’) and hard-code the passwords to access the Application ‘A’ in scripts or embed them in the calling application (say Application ‘B’) itself.

These hard-coded passwords pose a significant security threat as malicious users getting access to the script could easily decipher the password and unleash disaster.

Common Weakness Enumeration (CWE), a community developed dictionary of software weakness types has recently released the list of ‘Top 25 Most Dangerous Programming Errors’. The list is the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe. It leverages experiences in the development of the SANS Top 20 attack vectorsand MITRE’s Common Weakness Enumeration (CWE).

MITRE maintains the CWE web site, with the support of the US Department of Homeland Security’s National Cyber Security Division, presenting detailed descriptions of the top 25 programming errors along with authoritative guidance for mitigating and avoiding them.

Among the top 25 dangerous programming errors, use of hard-coded credentials is listed at No 11.

Hard-coding a secret password or cryptograpic key into your program is bad manners, even though it makes it extremely convenient – for skilled reverse engineers. While it might shrink your testing and support budgets, it can reduce the security of your customers to dust. If the password is the same across all your software, then every customer becomes vulnerable if (rather, when) your password becomes known. Because it’s hard-coded, it’s usually a huge pain for sysadmins to fix. And you know how much they love inconvenience at 2 AM when their network’s being hacked – about as much as you’ll love responding to hordes of angry customers and reams of bad press if your little secret should get out. Most of the CWE Top 25 can be explained away as an honest mistake; for this issue, though, customers won’t see it that way. Another way that hard-coded credentials arise is through unencrypted or obfuscated storage in a configuration file, registry key, or other location that is only intended to be accessible to an administrator. While this is much more polite than burying it in a binary program where it can’t be modified, it becomes a Bad Idea to expose this file to outsiders through lax permissions or other means.

So, use of hard-coded credentials is a very, very bad programming practice. But, the question is, how to avoid this? What is the alternative?

The good news is that ManageEngine Password Manager Pro provides effective ways to eliminate the hard-coded passwords. If you have applications in your infrastructure that require connecting to other applications using a password, they can query PMP to retrieve the password. One application (say Application A) would contact the PMP for the password to access another application (say Application B). On getting the password, ‘A’ would contact ‘B’ and all these have to happen without human intervention.

This way, the application-to-application (A-to-A) passwords can also follow good password management practices like periodic rotation, without the trouble of manually making the updates at many places. Same procedure can be used for Application-to-Database password management (A-to-DB).

PMP provides Password Management APIs using which any enterprise application or command line script can programatically query PMP and retrieve passwords to connect with other applications or databases.

PMP provides two flavors of the API for this purpose:

a comprehensive application API based on XML-RPC over HTTPS and

a command line interface for scripts over secure shell (SSH)

Both the forms use PKI authentication for allowing access to the PMP application through the API. The XML-RPC API also comes with a Java Wrapper API to make it easy for integrating it with Java applications.