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
Top 10 2010-A7-Insecure Cryptographic Storage
NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| Application Specific | Exploitability DIFFICULT |
Prevalence UNCOMMON |
Detectability DIFFICULT |
Impact SEVERE |
Application / Business Specific |
| Consider the users of your system. Would they like to gain access to protected data they aren’t authorized for? What about internal administrators? | Attackers typically don’t break the crypto. They break something else, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt. | The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access. | Failure frequently compromises all data that should have been encrypted. Typically this information includes sensitive data such as health records, credentials, personal data, credit cards, etc. | Consider the business value of the lost data and impact to your reputation. What is your legal liability if this data is exposed? Also consider the damage to your reputation. | |
|
Am I Vulnerable To 'Insecure Cryptographic Storage'?
The first thing you have to determine is which data is sensitive enough to require encryption. For example, passwords, credit cards, health records, and personal information should be encrypted. For all such data, ensure:
And more ... For a more complete set of problems to avoid, see the ASVS requirements on Cryptography (V7). |
How Do I Prevent 'Insecure Cryptographic Storage'?
The full perils of unsafe cryptography are well beyond the scope of this Top 10. That said, for all sensitive data deserving encryption, do all of the following, at a minimum:
|
|
Example Attack Scenarios
Scenario #1: An application encrypts credit cards in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing an SQL injection flaw to retrieve all the credit cards in cleartext. The system should have been configured to allow only back end applications to decrypt them, not the front end web application. Scenario #2: A backup tape is made of encrypted health records, but the encryption key is on the same backup. The tape never arrives at the backup center. Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be brute forced in 4 weeks, while properly salted hashes would have taken over 3000 years. |
References
OWASP For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Cryptography (V7).
External |
