Sin 12: Failing to Store and Protect Data Securely Summary

• Do think about the access controls your application explicitly places on objects, and the access controls objects inherit by default.

• Do realize that some data is so sensitive it should never be stored on a general purpose, production serverfor example, long-lived X.509 private keys, which should be locked away in specific hardware designed to perform only signing.

• Do leverage the operating system capabilities to secure secret and sensitive data.

• Do use appropriate permissions, such as access control lists (ACLs) or Permissions if you must store sensitive data.

• Do remove the secret from memory once you have used it.

• Do scrub the memory before you free it.

• Do not create world-writable objects in Linux, Mac OS X, and UNIX.

• Do not create objects with Everyone (Full Control) or Everyone (Write) access control entries (ACEs).

• Do not store key material in a demilitarized zone (DMZ). Operations such as signing and encryption should be performed further back than the DMZ.

• Do not embed secret data of any kind in your application. This includes passwords, keys, and database connection strings.

• Do not embed secret data of any kind in sample applications, such as those found in documentation or software development kits.

• Do not create your own secret encryption algorithms.

• Consider using encryption to store information that cannot be properly protected by an ACL, and signing to protect information from tampering.

• Consider never storing secrets in the first placecan you get the secret from the user at run time instead?