Securing Sensitive data in a program

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 game that 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 or she uses for an online bank account for your game program! . Now the user's bank account is only as much secure as your program chooses enables it to be.

There are simple steps in which you can take to secure sensitive data in your program:programs.

Prefer the system's authentication dialog (or any other mechanism provided by the 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 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.

Do not hard

...

code

...

sensitive data in

...

programs.

See MSC41-C. Never hard code sensitive information for details.

Disable memory dumps

...

.

Memory dumps are automatically created when your program crashes.

...

 They can contain information stored in any part of program memory.

...

#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);

  }
  ...

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.

Do not store sensitive data beyond its time of use in a

...

program.

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.

...

#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 all.

...

See 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 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 you must store sensitive data, encrypt it first.

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

...

1. they have certain requirements (documented with the library) for the key sizes and other properties. Choose keys

...

1. that satisfy these conditions.
2. Do not store the encryption keys (you can derive the key from the hash of the user's password or any other cryptographic mechanism

...

1. , provided the above condition holds). If the key is to be stored, store it securely.

Securely erase

...

sensitive data

...

from disk and

...

memory

...

.

1. Be aware of compiler optimization when erasing memory. (See MSC06-C.

...

1. Beware of compiler

...

1. optimizations.)
2. Use secure erase methods specified in

...

1. U.S. Department of Defense Standard 5220 [DOD 5220

...

1. ] or Peter Gutmann's paper

...

1. [Gutmann 1996].

Risk Assessment

If sensitive data is not handled correctly in a program, an attacker can gain access to it.

Related Vulnerabilities

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

Automated Detection

...

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

Other Languages

References

Wiki Markup\[[MSDN|AA. C References#MSDN]\] [{{EncodePointer()}}|http://msdn.microsoft.com/en-us/library/bb432254(VS.85).aspx], [{{DecodePointer()}}|http://msdn.microsoft.com/en-us/library/bb432242(VS.85).aspx]