This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Cryptographic Storage Cheat Sheet"
m |
(→Introduction) |
||
| Line 3: | Line 3: | ||
= Introduction = | = Introduction = | ||
| − | This article provides a simple model to follow when implementing | + | This article provides a simple model to follow when implementing solutions for data at rest.<br> |
== Architectural Decision == | == Architectural Decision == | ||
Revision as of 22:54, 19 December 2009
- 1 WORK IN PROGRESS
- 2 Introduction
- 3 Providing Cryptographic Functionality
- 3.1 Benefits
- 3.2 Basic Requirements
- 3.3 Secure Cryptographic Storage Design
- 3.3.1 Rule - Verify that password hashes are salted on a per-user basis when they are created.
- 3.3.2 Rule - Verify that access to any master secret(s) is protected from unauthorized access
- 3.3.3 Rule - Generate keys offline and store private keys with extreme care.
- 3.3.4 Rule - Never transmit private keys over insecure channels
- 3.3.5 Rule - Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion
- 3.3.6 Rule - Do not create cryptographic algorithms.
- 3.3.7 Rule - Do not use weak algorithms, such as MD5 / SHA1.
- 3.3.8 Rule - Under PCI Data Security Standard requirement 3, you must protect cardholder data.
- 4 Related Articles
- 5 Authors and Primary Editors
WORK IN PROGRESS
Introduction
This article provides a simple model to follow when implementing solutions for data at rest.
Architectural Decision
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
Benefits
Basic Requirements
Secure Cryptographic Storage Design
Rule - Verify that password hashes are salted on a per-user basis when they are created.
Rule - Verify that access to any master secret(s) is protected from unauthorized access
Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured (via tight file system permissions and controls), or securely encrypted and not easily decrypted by local or remote users Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is worthless if the database connection pool provides unencrypted access.
Rule - Generate keys offline and store private keys with extreme care.
Rule - Never transmit private keys over insecure channels
Rule - Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion
Rule - Do not create cryptographic algorithms.
Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.
Rule - Do not use weak algorithms, such as MD5 / SHA1.
Favor safer alternatives, such as SHA-256 or better. "Good" cryptographic algorithms change over time.
Rule - Under PCI Data Security Standard requirement 3, you must protect cardholder data.
PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards. Good practice is to never store unnecessary data,
Related Articles
OWASP - Testing for SSL-TLS, and OWASP Guide to Cryptography
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.manico[at]aspectsecurity.com
Dave Wichers - dave.wichers[at]aspectsecurity.com
