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"

From OWASP
Jump to: navigation, search
(→‎Introduction)
m
Line 17: Line 17:
 
== Secure Cryptographic Storage Design  ==
 
== Secure Cryptographic Storage Design  ==
  
−
=== Rule - Verify that password hashes are salted on a per-user basis when they are created. ===
+
That would be first,
 +
and closely behind it would be to use an implementation that at least had
 +
some cryptography experts involved in its creation. In other words, as much
 +
as you may want to, don't go out and implement your one AES or RC4 algorithm.
 +
In fact, if possible, use an implementation that is FIPS 140-2 certified.
 +
 
 +
=== 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. Ensure that implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.
 +
 
 +
=== Rule - User 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 - Verify that you are using a different random salt for each password hash ===
 +
 
 +
=== Rule - Verify that access to any secret key is protected from unauthorized access ===
  
−
=== 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 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.
 
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. ===
+
This applies to any secret key, not just a master key. Even derived keys should be protected from unauthorized access.
 +
 
 +
=== Rule - Generate keys offline and store private keys with extreme care ===
 +
 
 +
=== Rule - Never transmit secret keys over insecure channels ===
 +
 
 +
TODO: This also applies to private keys, and secret (aka, symmetric) keys as well.
 +
 
 +
=== Rule - Manage keys throughout the PKI lifecycle ===
  
−
=== Rule - Never transmit private keys over insecure channels ===
+
TODO: Also "manage crypto keys" covers the whole "key management" thing, of which key distribution is but a part. It covers the whole key lifecycle. NIST has some good stuff written up on this.
  
 
=== Rule - Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion ===
 
=== 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. ===
+
TODO: This probably could use further explanation especially how entropy used to seed
−
Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.
+
PRNGs plays an important role as well.
  
−
=== Rule - Do not use weak algorithms, such as MD5 / SHA1. ===
+
=== 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.
 
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. ===
+
=== 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,
 
PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards. Good practice is to never store unnecessary data,
  

Revision as of 09:47, 20 December 2009

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

That would be first, and closely behind it would be to use an implementation that at least had some cryptography experts involved in its creation. In other words, as much as you may want to, don't go out and implement your one AES or RC4 algorithm. In fact, if possible, use an implementation that is FIPS 140-2 certified.

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. Ensure that implementation has, at least, had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

= Rule - User 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 - Verify that you are using a different random salt for each password hash

Rule - Verify that access to any secret key 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.

This applies to any secret key, not just a master key. Even derived keys should be protected from unauthorized access.

Rule - Generate keys offline and store private keys with extreme care

Rule - Never transmit secret keys over insecure channels

TODO: This also applies to private keys, and secret (aka, symmetric) keys as well.

Rule - Manage keys throughout the PKI lifecycle

TODO: Also "manage crypto keys" covers the whole "key management" thing, of which key distribution is but a part. It covers the whole key lifecycle. NIST has some good stuff written up on this.

Rule - 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 - 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

OWASP – Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)

Other Articles in the OWASP Prevention Cheat Sheet Series

Authors and Primary Editors

Jim Manico - jim.manico[at]aspectsecurity.com

Dave Wichers - dave.wichers[at]aspectsecurity.com

Retrieved from "https://wiki.owasp.org/index.php?title=Cryptographic_Storage_Cheat_Sheet&oldid=75291"