|
|
| (111 intermediate revisions by 18 users not shown) |
| Line 1: |
Line 1: |
| − | = WORK IN PROGRESS = | + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | = Introduction =
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | This article provides a simple model to follow when implementing solutions for data at rest.<br>
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html Cryptographic Storage Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | == 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 - 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.
| |
| − | | |
| − | ==== Rule - Encrypt sensitive data with AES + CBC ====
| |
| − | ==== Rule - Check integrity with SHA-256 and a random “salt” ====
| |
| − | Use a Different Random Salt For Each Password Hash.
| |
| − | | |
| − | === 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.
| |
| − | | |
| − | http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Cryptographic_Ciphers
| |
| − | | |
| − | === 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 - Ensure that proper key management policy is enforced (e.g., key generation, distribution, revocation, expiration) ===
| |
| − | | |
| − | TODO: NIST has some good stuff written up on this.
| |
| − | | |
| − | ==== Rule - Generate keys offline ====
| |
| − | | |
| − | ==== Rule - Ensure that any secret key is protected from unauthorized access ====
| |
| − | | |
| − | Store any private keys with extreme care.
| |
| − | | |
| − | 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 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.
| |
| − | | |
| − | ==== Rule - Only transmit secret keys over secure channels ====
| |
| − | | |
| − | TODO: This also applies to private keys, and secret (aka, symmetric) keys as well.
| |
| − | | |
| − | This applies to any secret key, not just a master key. Even derived keys should be protected from unauthorized access.
| |
| − | | |
| − | ==== Rule - Use cryptographic keys for single purposes ====
| |
| − | | |
| − | Do not use keys for multiple purposes and don't needlessly share them with multiple parties as well. If you are encrypting
| |
| − | Bank Account #s and CC#s with Alice, Bob, and Carol, choose at least 2 keys-- one for encrypting the back account numbers and the other for encrypting credit card numbers. And if the parties that you are sharing them with have different trust levels, use a different key for each trust level.
| |
| − | | |
| − | For example, say Alice and Bob are applications that are highly trusted because they are applications that are written, maintained, and hosted within your company but Carol is less trusted then either Alice and Bob because it (pick one) was outsourced and not developed by your company or perhaps it is an application hosted by another company, that you would use
| |
| − | (at least) 2 keys--one for Alice & Bob, and a different one for Carol. (Of course this gets difficult to track as your number of keys increases so you probably will want to invest in a key manager of some sort.
| |
| − | | |
| − | ==== Rule - Ensure key revocation support ====
| |
| − | | |
| − | A proper PKI solution should be implemented to so that keys can be revoked and rendered immendiately invalid.
| |
| − | | |
| − | ==== Rule - Ensure timely key expiration ====
| |
| − | | |
| − | === Rule - Follow applicable regulations on use of cryptography ===
| |
| − | | |
| − | === 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 (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]
| |
| − | | |
| − | OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]
| |
| − | | |
| − | '''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
| |
| − | | |
| − | Kevin Wall - kevin.w.wall[at]gmail.com
| |
| − | | |
| − | [[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]
| |
