AppSec Blog

Top 25 Series - Rank 11 - Hardcoded Credentials

Talking about hard coded credentials to other developers, one of the first questions to come up is "where else to keep them?". A hard coded credential is usually a password used to obtain administrative access to software, or a password used by this same software to establish outbound connections, for example to connect to a database. Obviously, hard coded credentials (CWE 798) [1] are an important enough and common enough problem to warrant its inclusion as one of the top 25 software flaws.

So, back to the question: Where do you keep your credentials, if not in your code? In my opinion, credentials should be kept in a place that is hard to access for an attacker directly, but easy to access for an administrator to regularly change them. Leaving hard coded credentials littered throughout your file system does not help with either problem.

Finding an acceptable way to store credentials isn't always easy. The application does need access to the credentials, often without user interaction. This precludes the use of a user provided password. However, there are still a few tips that can be applied to secure and manage credentials better:

- store credentials in one central place. This may sound like putting all eggs into one basket. However, it enables the developer to focus their attention on protecting credentials in one place, and it makes it easier to change credentials perodically.

- limit access to the credentials. If credentials are stored in a file, on a particular user should have access to them.

- consider the use of mandatory access control systems like SELinux or a HIPS (Host based Intrusion Prevention System) to further limit access to the credential storage

- consider the use of a language specific password vault to store the credentials.

Another important part to remember is that "credentials" include more then usernames and passwords. In some cases encryption keys and SSL certificates may be considered credentials. One aspect I will save for later is the encryption of user provided credentials. This was covered earlier by Frank [2].

[1] http://cwe.mitre.org/data/definitions/798.html
[2] https://blogs.sans.org/appsecstreetfighter/2010/02/26/top-25-series-rank-10-missing-encryption-of-sensitive-data/

1 Comments

Posted March 10, 2010 at 6:37 PM | Permalink | Reply

Nathan Christiansen

We completely avoid hard-coded credentials for admin purposes.
We make the admin functions of our website only accessible to a small group inside the company and authenticate them via our company's internal Active Directory server through an application proxy which we program.

Post a Comment






Captcha


* Indicates a required field.