Page History

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 which stores the user's profile information and requires the user to enter a password, the user might choose the same password he uses for his online bank account for your game program. Now the user's bank account is only as secure as your program enables it to be.

...

Memory dumps are automatically created when your program crashes. These memory dumps can contain information stored in any part of program memory. Therefore memory dumps should be disabled before an application is shipped to users. See guideline 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 (see when a page is swapped out of the physical memory. (See next point for details with respect to 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. See guideline MEM06-C. Ensure that sensitive data is not written out to disk for details.

Do not store sensitive data in plaintext (

...

either on disk

...

or in memory).

See guidlien [MEM06-C. Ensure that sensitive data is not written out to disk|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 012001|AA. Bibliography#Viega 01]\] illustrates this:

...

1. Be aware of compiler optimization when erasing memory. (see See guideline MSC06-C. Be aware of compiler optimization when dealing with sensitive data.).

2. Wiki Markup
   Use secure erase methods specified in US Department of Defense Standard 5220 \[[DOD 5220|AA. Bibliography#DOD 5220]\] or Peter Gutmann's paper \[[Gutmann 961996|AA. Bibliography#Gutmann 96]\].

...

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

Related Guidelines

This rule appears in the Java Secure Coding Standard as : MSC31-J. Never hardcode sensitive information.

Bibliography

\[[MITRE 072007|AA. Bibliography#MITRE 07]\] [CWE-798|http://cwe.mitre.org/data/definitions/798.html], "Use of Hard-coded Credentials," [CWE-326|http://cwe.mitre.org/data/definitions/326.html], "Inadequate Encryption Strength," [CWE-311|http://cwe.mitre.org/data/definitions/311.html], "Missing Encryption of Sensitive Data"
\[[DOD 5220|AA. Bibliography#DOD 5220]\]
\[[Gutmann 961996|AA. Bibliography#Gutmann 96]\]
\[[Lewis 062006|AA. Bibliography#Lewis 06]\]
\[[Viega 012001|AA. Bibliography#Viega 01]\]

...