...
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 , as because doing so would at least not increase the footprint of the sensitive data.
...
This is considered very bad programming practice , as because it enforces the requirement of the development environment to be secure.
...
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 recommendation 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 with respect to 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 this successfully, but it never hurts to try. See guideline recommendation 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 [recommendation MEM06-C. Ensure that sensitive data is not written out to disk.
| Wiki Markup |
|---|
].
While using a password, consider storing its hash instead of plaintext. Use the hash for comparisons and other purposes. The following code \[[Viega 2001|AA. Bibliography#Viega 01]\] illustrates this: |
...
- 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 the user's password or any other cryptographic mechanism, provided the above condition holds). If the key is to be stored, store it securely.
...
- Be aware of compiler optimization when erasing memory. (See guideline recommendation MSC06-C. Be aware of compiler optimization when dealing with sensitive data.)
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 1996|AA. Bibliography#Gutmann 96]\].
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Java The CERT Oracle Secure Coding Standard for Java: MSC03-J. Never hardcode sensitive information
Bibliography
MITRE CWE: CWE-798, "Use of Hard-coded Credentials"
MITRE CWE: CWE-326, "Inadequate Encryption Strength"
MITRE CWE: CWE-311, "Missing Encryption of Sensitive Data"
Bibliography
| Wiki Markup |
|---|
| Wiki Markup |
\[[MITRE 2007|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 1996|AA. Bibliography#Gutmann 96]\]
\[[Lewis 2006|AA. Bibliography#Lewis 06]\]
\[[Viega 2001|AA. Bibliography#Viega 01]\] |
...