Page History

...

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.

...

#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>

int main(int argc, char **argv){

  struct rlimit rlim;

  getrlimit(RLIMIT_CORE, &rlim);
  rlim.rlim_max = rlim.rlim_cur = 0;

  if(setrlimit(RLIMIT_CORE, &rlim)) {
    // unable to secure data.
    exit(-1);

  }
  ...

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. Here's a simple way to lock memory when possible#1:

#include <sys/mman.h>
void *locking_alloc(size_t numbytes) {
     static short have_warned = 0;
     void *mem = malloc(numbytes);
     if(mlock(mem, numbytes) && !have_warned) {
       /* We probably do not have permission.
        * Sometimes, it might not be possible to lock enough memory.
        */
       fprintf(stderr, "Warning: Using insecure memory!\n");
       have_warned = 1;
     }     
     return mem;
}

For Unlocking the locked memory:

munlock(mem, numbytes)

There are certain negative consequences of above method. Not letting the page get swapped might cause a performance hit on the system. Also, if you lock two buffers which are on the same page and then unlock one of them, the other would also get unlocked. Typically, it is recommended to keep all the sensitive data in a single chunk (using structures, within the same virtual page) and then lock/unlock this structure. NOTE: these calls are privileged and might not be able to lock a page on certain systems at allPlease refer MEM06-C. Ensure that sensitive data is not written out to disk for details.

Do not store the sensitive data on disk in plaintext

...

Encrypt the data before storing it, if you must

1. 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.
2. 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.
3. 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)

1. Be aware of compiler optimization MSC06-C. Be aware of compiler optimization when dealing with sensitive data while erasing memory.
2. 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.

...