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 same passwords everywhere. So, even if your program is a simple game which stores user's profile information and requires user to enter a password, the user might choose the same password he uses for his online bank account for your game program! Now user's bank account is only as much secure as your program chooses it to be.
There are simple steps in which you can secure sensitive data in your program:
Prefer system's authentication dialog (or any other mechanism provided by OS) for authentication to privileged services
If you are accessing some privileged service already installed on the system, most likely that service will have some mechanism to take password from the user. Before asking the user directly for username and password from your application, check if that service itself authenticates the user in some way. Let that service handle the authentication as it would atleast not increase footprint of the sensitive data.
Do not hard-code the sensitive data in program.
This is considered as very bad programming practice as it enforces the requirement of development environment to be secure.
Disable memory dumps in your program.
Memory dumps are automatically created when your program crashes. These memory dumps can contain information stored in any part of program memory. It is advised to disable memory dumps in the program that is being shipped to the user. Please refer MEM06-C. Ensure that sensitive data is not written out to disk for details.
Do not store the sensitive data for long time (beyond its use) in the program.
Sensitive data that is stored in memory can get written to disk (see next point for details wrt keeping sensitive data on disk) when a page is swapped out of the physical memory. You may be able to "lock" your data to keep it from swapping out. Your program will generally need administrative privileges to do this successfully, but it never hurts to try. Please refer MEM06-C. Ensure that sensitive data is not written out to disk for details.
Do not store the sensitive data in plaintext (neither on disk, nor in memory)
See MEM06-C. Ensure that sensitive data is not written out to disk.
While using passwords, consider storing its hash instead of plaintext. Use the hash for comparisons and other purposes. The following code [[#1]] illustrates this:
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));
}
Encrypt the data before storing it, if you must
- If encrypting or hashing sensitive data, do not implement your own encryption functions (or library). Use proven secure crypto libraries which have been extensively tested for security.
- If using standard crypto libraries, be aware that there are certain requirements (documented with the library) for the key sizes and other properties. Choose keys satisfying these conditions.
- Do not store the encryption keys (you can derive the key from the hash of user's password or any other cryptographic mechanism provided above condition holds). If the key is to be stored, store it securely.
Securely erase the sensitive data (from disk and from memory)
- Be aware of compiler optimization MSC06-C. Be aware of compiler optimization when dealing with sensitive data while erasing memory.
Use secure erase methods specified in US Department of Defense Standard 5220 [[#2]] or Peter Gutmann's paper [[#3]].
Risk Assessment
If sensitive data is not handled correctly in a program, attacker can gain access to it.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
MSC18-C |
medium |
probable |
medium |
P8 |
L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
- John Viega, Protecting sensitive data in memory, Feb 2001
- US DoD Standard 5220.22-M
- Peter Gutmann, Secure Deletion of Data from Magnetic and Solid-State Memory, July 1996
- Richard Lewis, Security considerations when handling sensitive data