Many applications need to handle sensitive data either in memory or on disk. If this sensitive data is not protected properly, it might lead to loss of secrecy or integrity of the data. It is very difficult (or expensive) to completely secure all the sensitive data. Users tend to use the same passwords everywhere. So even if your program is a simple game that stores the user's profile information and requires the user to enter a password, the user might choose the same password he or she uses for an online bank account for your game program. Now the user's bank account is only as secure as your program enables it to be.
There are simple steps you can take to secure sensitive data in your programs.
If you are accessing some privileged service already installed on the system, most likely that service will have some mechanism to take a password from the user. Before asking the user for a user name and password from your application, check if the service itself authenticates the user in some way. If so, let the service handle the authentication because doing so would at least not increase the footprint of the sensitive data.
See MSC41-C. Never hard code sensitive information for details.
Memory dumps are automatically created when your program crashes. They can contain information stored in any part of program memory. Therefore, memory dumps should be disabled before an application is shipped to users. See MEM06-C. Ensure that sensitive data is not written out to disk for details.
Sensitive data that is stored in memory can get written to disk when a page is swapped out of the physical memory. (See next point for details about keeping sensitive data on disk.) You may be able to "lock" your data to keep it from swapping out. Your program will generally need administrative privileges to do so successfully, but it never hurts to try. See MEM06-C. Ensure that sensitive data is not written out to disk for details.
See MEM06-C. Ensure that sensitive data is not written out to disk.
While using a password, consider storing its hash instead of plaintext. Use the hash for comparisons and other purposes. The following code [Viega 2001] illustrates:
int validate(char *username) { char *password; char *checksum; password = read_password(); checksum = compute_checksum(password); erase(password); /* Securely erase password */ return !strcmp(checksum, get_stored_checksum(username)); } |
If sensitive data is not handled correctly in a program, an attacker can gain access to it.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MSC18-C | Medium | Probable | Medium | P8 | L2 |
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Tool | Version | Checker | Description |
---|---|---|---|
CodeSonar | HARDCODED.AUTH HARDCODED.KEY HARDCODED.SALT MISC.PWD.PLAIN MISC.PWD.PLAINTRAN | Hardcoded Authentication Hardcoded Crypto Key Hardcoded Crypto Salt Plaintext Storage of Password Plaintext Transmission of Password | |
PC-lint Plus | 586 | Partially supported: reports functions that read passwords from the user or that take a password as an argument instead of prompting the user as well as insecure password erasure | |
Polyspace Bug Finder | Checks for:
Rec. partially covered. |
CERT Oracle Secure Coding Standard for Java | MSC03-J. Never hard code sensitive information |
CERT C Secure Coding Standard | MSC41-C. Never hard code sensitive information |
MITRE CWE | CWE-259, Use of Hard-coded Password CWE-261, Weak Cryptography for Passwords CWE-311, Missing encryption of sensitive data CWE-319, Cleartext Transmission of Sensitive Information CWE-321, Use of Hard-coded Cryptographic Key CWE-326, Inadequate encryption strength CWE-798, Use of hard-coded credentials |