Difference between revisions of "Top 10 2010-A7-Insecure Cryptographic Storage"

From OWASP
Jump to: navigation, search
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Top_10_2010:TopTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}  
+
{{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A6-Security Misconfiguration|next=A8-Failure to Restrict URL Access}}
  
<center>
+
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{| style="align:center; text-align:center; border:2px solid #4F81BD; background-color:#F2F2F2; padding=2;"
+
{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}
|- style="background-color: #4F81Bd; color: #000000;"
+
{{Top_10_2010:SummaryTableValue-3-Template|Prevalence|UNCOMMON}}
! Threat Agents !! Attack Vectors
+
{{Top_10_2010:SummaryTableValue-3-Template|Detectability|DIFFICULT}}
! colspan="2" | Security Weakness
+
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
! Technical Impact
+
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
! Business Impacts
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the users of your system. Would they like to gain access to protected data they aren’t authorized for? What about internal administrators?</td>
|-
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.
| style="background-color: #D9D9D9; color: #000000;" | ______
+
</td>
| style="background-color: #FF0000; color: #000000;" | Exploitability<br>EASY
+
    <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #FFFF00; color: #000000;" | Prevalence<br>UNCOMMON
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #FFB200; color: #000000;" | Detectability<br>DIFFICULT
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #FF0000; color: #000000;" | Impact<br>SEVERE
+
{{Top_10_2010:SummaryTableEndTemplate}}
| style="background-color: #D9D9D9; color: #000000;" | ______
+
|-
+
| style="text-align: left; border: 2px solid #FFFFFF;" | Consider the users of your system. Would they like to gain access to protected data they aren’t authorized for? What about internal administrators?
+
| style="text-align: left; border: 2px solid #FFFFFF;" | 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.
+
| colspan="2" style="text-align: left;border: 2px solid #FFFFFF;" | 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.
+
| style="text-align: left; border: 2px solid #FFFFFF;" | 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.
+
| style="text-align: left; border: 2px solid #FFFFFF;" | 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.
+
|}
+
</center>
+
  
{{Top_10_2010:SubsectionVulnerableTemplate|Injection|
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=7}}
 
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:
 
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:
 
# It is encrypted everywhere it is stored long term, particularly in backups of this data.
 
# It is encrypted everywhere it is stored long term, particularly in backups of this data.
# Only authorized users can access decrypted copies of the data (i.e., access control – See A4 and A8).
+
# Only authorized users can access decrypted copies of the data (i.e., access control – See [[Top_10_2010-A4 | A4]] and [[Top_10_2010-A8 | A8]]).
 
# A strong standard encryption algorithm is used.
 
# A strong standard encryption algorithm is used.
 
#A strong key is generated, protected from unauthorized access, and key change is planned for.
 
#A strong key is generated, protected from unauthorized access, and key change is planned for.
And more ... For a more complete set of problems to avoid, see the ASVS requirements on Cryptography (V7)
+
And more ... For a more complete set of problems to avoid, see the [[ASVS | ASVS requirements on Cryptography (V7)]].
}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=7}}
 
+
{{Top_10_2010:SubsectionPreventionTemplate|Injection|
+
 
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:
 
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:
 
# Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.
 
# Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.
Line 40: Line 29:
 
# Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.
 
# Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.
 
# Ensure all keys and passwords are protected from unauthorized access.
 
# Ensure all keys and passwords are protected from unauthorized access.
}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=7}}
 
+
'''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.
{{Top_10_2010:SubsectionExampleTemplate|Injection|
+
'''Scenario #''': 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 a 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 #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.
 
'''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.
}}
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=7}}
 
+
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
  
{{Top_10_2010:SubsectionReferencesTemplate|Injection|
+
For a more complete set of requirements and problems to avoid in this area, see the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS requirements on Cryptography (V7)].
For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Cryptography (V7).
+
* [[Top_10_2007-Insecure_Cryptographic_Storage | OWASP Top 10-2007 on Insecure Cryptographic Storage]]
OWASP Top 10-2007 on Insecure Cryptographic Storage ESAPI Encryptor API OWASP Development Guide: Chapter on Cryptography OWASP Code Review Guide: Chapter on Cryptography
+
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encryptor.html ESAPI Encryptor API]
|
+
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
 +
* [[Codereview-Cryptography | OWASP Code Review Guide: Chapter on Cryptography]]
 +
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
 +
* [http://cwe.mitre.org/data/definitions/310.html CWE Entry 310 on Cryptographic Issues]
 +
* [http://cwe.mitre.org/data/definitions/312.html CWE Entry 312 on Cleartext Storage of Sensitive Information]
 +
* [http://cwe.mitre.org/data/definitions/326.html CWE Entry 326 on Weak Encryption]
 +
{{Top_10_2010:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|useprev=2010PrevLink|usenext=2010NextLink|prev=A6-Security Misconfiguration|next=A8-Failure to Restrict URL Access}}
  
}}
+
[[Category:OWASP Top Ten Project]]
<br> {{Top_10_2010:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
+

Latest revision as of 11:14, 24 October 2011

← A6-Security Misconfiguration
Top 10 Introduction
Top 10 Risks
A8-Failure to Restrict URL Access →
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:

  1. It is encrypted everywhere it is stored long term, particularly in backups of this data.
  2. Only authorized users can access decrypted copies of the data (i.e., access control – See A4 and A8).
  3. A strong standard encryption algorithm is used.
  4. A strong key is generated, protected from unauthorized access, and key change is planned for.

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:

  1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.
  2. Ensure offsite backups are encrypted, but the keys are managed and backed up separately.
  3. Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.
  4. Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.
  5. Ensure all keys and passwords are protected from unauthorized access.
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

← A6-Security Misconfiguration
Top 10 Introduction
Top 10 Risks
A8-Failure to Restrict URL Access →

© 2002-2010 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png