Cryptographic Storage Cheat Sheet
- 1 Introduction
- 2 Providing Cryptographic Functionality
- 2.1 Benefits
- 2.2 Basic Requirements
- 2.3 Secure Cryptographic Storage Design
- 2.3.1 Rule - Only store sensitive data that you need
- 2.3.2 Rule - Only use strong cryptographic algorithms
- 2.3.3 Rule - Only use widely accepted implementations of cryptographic algorithms
- 2.3.4 Rule - Ensure that any secret key is protected from unauthorized access
- 184.108.40.206 Rule - Define a key lifecycle
- 220.127.116.11 Rule - Store unencrypted keys away from the encrypted data
- 18.104.22.168 Rule - Protect keys in a key vault
- 22.214.171.124 Rule - Document concrete procedures for managing keys through the lifecycle
- 126.96.36.199 Rule - Build support for changing keys periodically
- 188.8.131.52 Rule - Document concrete procedures to handle a key compromise
- 2.3.5 Rule - Follow applicable regulations on use of cryptography
- 3 Related Articles
- 4 Authors and Primary Editors
This article provides a simple model to follow when implementing solutions for data at rest.
An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide variety of products, methods and mechanisms for cryptographic storage that this cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.
Providing Cryptographic Functionality
Secure Cryptographic Storage Design
Rule - Only store sensitive data that you need
Many eCommerce businesses use payment providers that store the credit card for recurring billing. This offloads the burden of keeping credit card numbers safe.
Rule - Only use strong cryptographic algorithms
Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 / SHA1/ Favor safer. The definition of a "strong" cryptographic algorithms change over time.
This is a good default if one doesn't have AES and one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC, None of these cipher modes are authentication encryption modes. (That's why I added it explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc then some of these authentication encryption modes probably should be preferred.
Use salts when appropriate. Should note that integrity should be use a MAC (i.e., a keyed hash) and not a MIC (message integrity code). A MIC can be used as a keyed hash via
MIC(msg) = Secure_Hash( salt + msg )
but that is not as good as using something like HMAC-SHA1 or even better, HMAC-SHA256.
Rule - Store the hash value of passwords
Store the hashed value of the password. Salt each hash. Use a different random salt for each password hash. Never store the clear text password or an encrypted version of the password.
Cryptographic framework for password hashing is described in PKCS #5 v2.1: Password-Based Cryptography Standard. Specific secure password hashing algorithms exist such as bcrypt, scrypt. Implementations of secure password hashing exist for PHP (phpass), ASP.NET (ASP.NET 2.0 Security Practices), Java (OWASP Hashing Java).
Rule - Ensure that random numbers are cryptographically strong
Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion.
TODO: This probably could use further explanation especially how entropy used to seed PRNGs plays an important role as well.
Rule - Only use widely accepted implementations of cryptographic algorithms
Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Use widely accepted algorithms and widely accepted implementations only. Ensure that an implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.
Rule - Only use strong cryptographic cipher modes
Use cryptographic cipher modes that offer both authenticity and confidentiality
ECB should almost unequivocally be avoided. If you use a cipher mode that treats a block cipher as a streaming mode, such as OFB or CFB, be careful you don't repeat the IV for the same encryption key. In general CBC is a decent cipher mode to use if message authenticity is not an issue and it a cipher mode that is almost always available. Better cipher modes are ones that offer both authenticity and confidentiality such as those mentioned under the Wikipedia "Authenticated Encryption" article. See the "see also" section of <http://en.wikipedia.org/wiki/Authenticated_encryption> for a list of such cipher modes.
Rule - Define a key lifecycle
The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.
Rule - Store unencrypted keys away from the encrypted data
If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.
Rule - Protect keys in a key vault
Ideally, keys should remain in a protected key vault at all times. In particular ensure that there is a gap between the threat vectors with direct access to the data and the threat vectors with direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).
Rule - Document concrete procedures for managing keys through the lifecycle
These procedures must be written down and the key custodians must be adequately trained.
Rule - Build support for changing keys periodically
Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).
Rule - Document concrete procedures to handle a key compromise
Rule - Follow applicable regulations on use of cryptography
Rule - Under PCI DSS requirement 3, you must protect cardholder data
PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards.
Other Articles in the OWASP Prevention Cheat Sheet Series
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- SQL Injection Prevention Cheat Sheet
- Transport Layer Protection Cheat Sheet
Authors and Primary Editors
Jim Manico - jim[at]manico.net
Kevin Wall - kevin.w.wall[at]gmail.com
Kevin Kenan - kevin[at]k2dd.com