Difference between revisions of "Password Storage Cheat Sheet"

From OWASP
Jump to: navigation, search
m (cleanup, added rule 4)
(Do not limit the character set or length of credentials)
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
 
 
= Introduction =
 
= Introduction =
  
This article provides guidance on how to properly store passwords for user authentication in order to help prevent password theft.
+
Media covers the theft of large collections of passwords on an almost daily basis. Media coverage of password theft discloses the password storage scheme, the weakness of that scheme, and often discloses a large population of compromised credentials that can affect multiple web sites or other applications. This article provides guidance on properly storing passwords, secret question responses, and similar credential information. Proper storage helps prevent theft, compromise, and malicious use of credentials.
 +
Information systems store passwords and other credentials in a variety of protected forms. Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL Injection. Protected passwords can also be stolen from artifacts such as logs, dumps, and backups.
  
Passwords are frequently stored encrypted or as clear text. Clear text passwords can be read directly by the database's administrator, super users or via data theft by SQL Injection. If encrypted, these same techniques may also allow the attacker to gain access to the decryption key as well. Database backup media is also vulnerable to password theft if these passwords are included on the backup. It is recommended that you avoid storing the clear text password or an encrypted version of the password. Passwords should be strongly hashed as described below.
+
Specific guidance herein protects against stored credential theft but the bulk of guidance aims to prevent credential compromise. That is, this guidance helps designs resist revealing users’ credentials or allowing system access in the event threats steal protected credential information. For more information and a thorough treatment of this topic, refer to the Secure Password Storage Threat Model here [http://goo.gl/Spvzs http://goo.gl/Spvzs].
  
= Password Storage Rules =
+
= Guidance =
  
Passwords are secrets that only the account owner should know. For the system that uses these passwords to authenticate its users, there is no reason to decrypt them under any circumstances. It is crucial that passwords are stored in a way that allows them to be verified but not reversed in any way, even by insiders. 
+
==  Do not limit the character set and set long max lengths for credentials ==
  
== Rule 1: Use An Adaptive One-Way Function ==
+
Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, facilitate certain simple attacks such as brute force.
  
Hash algorithms have the ability to transform data from one format (plaintext) to another (hash value) in a manner such that this process is not algorithmically reversible. This means that you can hash something, but there is no unhash. This is perfect for password storage since we wish to verify but not uncover the original value of the password. In addition an ideal password hashing algorithm will be deliberately "slow" in order to help mitigate brute-force password guessing attacks.
+
Do not apply short or no length, character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.
  
As such general hashing algorithms (eg, MD5, SHA-1/256/512) are not recommended for password storage. Instead an algorithm specifically designed for the purpose should be used such as bcrypt, PBKDF2 or scrypt.
+
A reasonable long password length is 160. Very long password policies can lead to DOS in certain circumstances[http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/].
  
== Rule 2: Use a Long Cryptographically Random Per-User Salt ==
+
== Use a cryptographically strong credential-specific salt ==
  
If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to hashing only the password:
+
A salt is fixed-length cryptographically-strong random value. Append credential data to the salt and use this as input to a protective function. Store the protected form appended to the salt as follows:
  
# Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can detect if multiple users share the same password, especially if the number of passwords in the database is large.
+
<code>[protected form] = [salt] + protect([protection func], [salt] + [credential]);</code>
# An attacker can also use a list of precomputed hashed values (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.
+
  
In order to avoid this weakness, a per user account salt must be introduced into the hashing process.  Such a salt should be appended to the beginning of the user supplied password before the combined value is hashed. The salt needs to be unique per user account. As long as you make use of one of the algorithms specifically designed for password storage (see list above) salting is managed internally and it shouldn't be necessary to manually add additional salt values.
+
Follow these practices to properly implement credential-specific salts:
  
=== Recommendation: Make it hard to steal the salt ===
+
* Generate a unique salt upon creation of each stored credential (not just per user or system wide);
 +
* Use cryptographically-strong random [*3] data;
 +
* As storage permits, use a 32bit or 64b salt (actual size dependent on protection function);
 +
* Scheme security does not depend on hiding, splitting, or otherwise obscuring the salt.
  
There are a number of additional recommended enhancements to the basic salting mechanism for consideration:
+
Salts serve two purposes: 1) prevent the protected form from revealing two identical credentials and 2) augment entropy fed to protecting function without relying on credential complexity. The second aims to make pre-computed lookup attacks [*2] on an individual credential and time-based attacks on a population intractable.
* Have an additional 'system' salt that is a fixed value for the entire system. This should be stored in a configuration file somewhere. This fixed value would not have to be included every backup, making it even harder for an attacker to compromise all elements required to calculate the hash value properly.
+
* Embedding a portion of the system salt in the source code. This wouldn't be that helpful for open source code, but for custom applications, having part of your system salt in the code would be yet one more item required by an attacker to calculate the hash value properly.
+
* Generating a new salt for an account each time that user's password is changed.
+
* An additional password storage defense mechanism involves storing the salt in a different location than the password hash. Use of the server's filesystem is one commonly used mechanism for salt isolation, assuming the password hashes are stored in different location such as a database or LDAP server. This defense mechanism reduces the risk of password theft when the database file is stolen, since the salts will not be included with the database data. Be careful to ensure that both the password hashes and the salts are not backed up together, they should also be backed up in isolation.
+
  
== Rule 3: Iterate the hash ==
+
== Impose infeasible verification on attacker ==
  
If a password database is ever compromised, one of the primary things defending the hashed passwords from being broken is the computational time required to guess password values. As such, we recommend slowing down the hash computation by iterating the hash operation many times. While hashing the password many times does slow down hashing for both attackers and typical users, typical users don't really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing, so hashing many times can slow down an attacker by a factor of N (# of iterations) while not noticeably affecting the typical user. A minimum of 1000 operations was recommended in the RSA PKCS5 standard in 2000, a value that should be doubled every 2 years. Therefore, in 2012, it is recommended that 64,000 iterations be considered. You should measure the time required and make sure that its as large as possible without providing a significantly noticeable delay when your users authenticate.
+
The function used to protect stored credentials should balance attacker and defender verification. The defender needs an acceptable response time for verification of users’ credentials during peak use. However, the time required to map <code><credential> → <protected form></code>  must remain beyond threats’ hardware (GPU, FPGA) and technique (dictionary-based, brute force, etc) capabilities.
  
Standard Hash Iteration Approaches:<br/>
+
Two approaches facilitate this, each imperfectly.
[http://en.wikipedia.org/wiki/Bcrypt bcrypt] [http://en.wikipedia.org/wiki/Bcrypt#See_also implementations]<br/>
+
[http://en.wikipedia.org/wiki/PBKDF2 PBKDF2] [http://en.wikipedia.org/wiki/PBKDF2#Implementations implementations]
+
  
== Rule 4 : Encrypt the Hash Data With a Keyed Algorithm ==
+
=== Leverage an adaptive one-way function ===
  
 +
Adaptive one-way functions compute a one-way (irreversible) transform. Each function allows configuration of ‘work factor’. Underlying mechanisms used to achieve irreversibility and govern work factors (such as time, space, and parallelism) vary between functions and remain unimportant to this discussion.
  
= References =
+
Select:
 +
 
 +
* PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required;
 +
* Scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.
 +
 
 +
Example protect() pseudo-code follows:
 +
 
 +
<code>return [salt] + pbkdf2([salt], [credential], c=10000); </code>
 +
 
 +
Designers select one-way adaptive functions to implement protect() because these functions can be configured to cost (linearly or exponentially) more than a hash function to execute. Defenders adjust work factor to keep pace with threats’ increasing hardware capabilities. Those implementing adaptive one-way functions must tune work factors so as to impede attackers while providing acceptable user experience and scale.
 +
 
 +
Additionally, adaptive one-way functions do not effectively prevent reversal of common dictionary-based credentials (users with password ‘password’) regardless of user population size or salt usage.
 +
 
 +
==== Work Factor ====
 +
 
 +
Since resources are normally considered limited, a common rule of thumb for tuning the work factor (or cost) is to make protect() run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget. So, if the registration and authentication's cases accept protect() taking up to 1 second, you can tune the cost so that it takes 1 second to run on your hardware. This way, it shouldn't be so slow that your users become affected, but it should also affect the attackers' attempt as much as possible.
 +
 
 +
While there is a minimum number of iterations recommended to ensure data safety, this value changes every year as technology improves. An example of the iteration count chosen by a well known company is the 10,000 iterations Apple uses for its iTunes passwords (using PBKDF2)[http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf](PDF file). However, it is critical to understand that a single work factor does not fit all designs. Experimentation is important.[*6]
 +
 
 +
=== Leverage Keyed functions ===
 +
 
 +
Keyed functions, such as HMACs, compute a one-way (irreversible) transform using a private key and given input. For example, HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes infeasible size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’).
 +
Designers protecting stored credentials with keyed functions:
 +
 
 +
* Use a single “site-wide” key;
 +
* Protect this key as any private key using best practices;
 +
* Store the key outside the credential store (aka: not in the database);
 +
* Generate the key using cryptographically-strong pseudo-random data;
 +
* Do not worry about output block size (i.e. SHA-256 vs. SHA-512).
 +
 
 +
Example protect() pseudo-code follows:
 +
 
 +
<code>return [salt] + HMAC-SHA-256([key], [salt] + [credential]);  </code>
 +
 
 +
Upholding security improvement over (solely) salted schemes relies on proper key management.
 +
 
 +
== Design password storage assuming eventual compromise ==
 +
 
 +
The frequency and ease with which threats steal protected credentials demands “design for failure”. Having detected theft, a credential storage scheme must support continued operation by marking credential data compromised and engaging alternative credential validation workflows as follows:
 +
 
 +
# Protect the user’s account
 +
## Invalidate authentication ‘shortcuts’ disallowing login without 2nd factors or secret questions.
 +
## Disallow changes to user accounts such as editing secret questions and changing account multi-factor configuration settings.
 +
# Load and use new protection scheme
 +
## Load a new (stronger) protect(credential) function
 +
## Include version information stored with form
 +
## Set ‘tainted’/‘compromised’ bit until user resets credentials
 +
## Rotate any keys and/or adjust protection function parameters (iter count)
 +
## Increment scheme version number
 +
# When user logs in:
 +
## Validate credentials based on stored version (old or new); if old demand 2nd factor or secret answers
 +
## Prompt user for credential change, apologize, & conduct out-of-band confirmation
 +
## Convert stored credentials to new scheme as user successfully log in
 +
 
 +
= References=
 +
 
 +
* [1] Morris, R. Thompson, K., Password Security: A Case History, 04/03/1978, p4: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps
 +
* [2] Space-based (Lookup) attacks: Space-time Tradeoff: Hellman, M., Crypanalytic Time-Memory Trade-Off, Transactions of Information Theory, Vol. IT-26, No. 4, July, 1980 http://www-ee.stanford.edu/~hellman/publications/36.pdf Rainbow Tables -http://ophcrack.sourceforge.net/tables.php
 +
* [3] For example: http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html
 +
* [4] Kalski, B., PKCS #5: Password-Based Cryptography Specification Version 2.0, IETF RFC 2898, September, 2000, p9 http://www.ietf.org/rfc/rfc2898.txt
 +
* [5] Percival, C., Stronger Key Derivation Via Sequential Memory-Hard Functions, BSDCan ‘09, May, 2009 http://www.tarsnap.com/scrypt/scrypt.pdf
 +
* [6] For instance, one might set work factors targeting the following run times: (1) Password-generated session key - fraction of a second; (2) User credential - ~0.5 seconds; (3) Password-generated site (or other long-lived) key - potentially a second or more.
 +
 
 +
= Authors and Primary Editors =
 +
 
 +
John Steven - john.steven[at]owasp.org
 +
 
 +
= Other Cheatsheets =
  
# Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard].
 
# Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt].
 
# Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([[Hashing Java|Hashing in Java]]).
 
# Much of this article came from the original OWASP [[Hashing Java|Hashing in Java]] article.
 
 
{{Cheatsheet_Navigation}}
 
{{Cheatsheet_Navigation}}
 +
 
[[Category:Cheatsheets]]
 
[[Category:Cheatsheets]]

Revision as of 12:42, 7 October 2013

Contents

Introduction

Media covers the theft of large collections of passwords on an almost daily basis. Media coverage of password theft discloses the password storage scheme, the weakness of that scheme, and often discloses a large population of compromised credentials that can affect multiple web sites or other applications. This article provides guidance on properly storing passwords, secret question responses, and similar credential information. Proper storage helps prevent theft, compromise, and malicious use of credentials. Information systems store passwords and other credentials in a variety of protected forms. Common vulnerabilities allow the theft of protected passwords through attack vectors such as SQL Injection. Protected passwords can also be stolen from artifacts such as logs, dumps, and backups.

Specific guidance herein protects against stored credential theft but the bulk of guidance aims to prevent credential compromise. That is, this guidance helps designs resist revealing users’ credentials or allowing system access in the event threats steal protected credential information. For more information and a thorough treatment of this topic, refer to the Secure Password Storage Threat Model here http://goo.gl/Spvzs.

Guidance

Do not limit the character set and set long max lengths for credentials

Some organizations restrict the 1) types of special characters and 2) length of credentials accepted by systems because of their inability to prevent SQL Injection, Cross-site scripting, command-injection and other forms of injection attacks. These restrictions, while well-intentioned, facilitate certain simple attacks such as brute force.

Do not apply short or no length, character set, or encoding restrictions on the entry or storage of credentials. Continue applying encoding, escaping, masking, outright omission, and other best practices to eliminate injection risks.

A reasonable long password length is 160. Very long password policies can lead to DOS in certain circumstances[1].

Use a cryptographically strong credential-specific salt

A salt is fixed-length cryptographically-strong random value. Append credential data to the salt and use this as input to a protective function. Store the protected form appended to the salt as follows:

[protected form] = [salt] + protect([protection func], [salt] + [credential]);

Follow these practices to properly implement credential-specific salts:

  • Generate a unique salt upon creation of each stored credential (not just per user or system wide);
  • Use cryptographically-strong random [*3] data;
  • As storage permits, use a 32bit or 64b salt (actual size dependent on protection function);
  • Scheme security does not depend on hiding, splitting, or otherwise obscuring the salt.

Salts serve two purposes: 1) prevent the protected form from revealing two identical credentials and 2) augment entropy fed to protecting function without relying on credential complexity. The second aims to make pre-computed lookup attacks [*2] on an individual credential and time-based attacks on a population intractable.

Impose infeasible verification on attacker

The function used to protect stored credentials should balance attacker and defender verification. The defender needs an acceptable response time for verification of users’ credentials during peak use. However, the time required to map <credential> → <protected form> must remain beyond threats’ hardware (GPU, FPGA) and technique (dictionary-based, brute force, etc) capabilities.

Two approaches facilitate this, each imperfectly.

Leverage an adaptive one-way function

Adaptive one-way functions compute a one-way (irreversible) transform. Each function allows configuration of ‘work factor’. Underlying mechanisms used to achieve irreversibility and govern work factors (such as time, space, and parallelism) vary between functions and remain unimportant to this discussion.

Select:

  • PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required;
  • Scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.

Example protect() pseudo-code follows:

return [salt] + pbkdf2([salt], [credential], c=10000);

Designers select one-way adaptive functions to implement protect() because these functions can be configured to cost (linearly or exponentially) more than a hash function to execute. Defenders adjust work factor to keep pace with threats’ increasing hardware capabilities. Those implementing adaptive one-way functions must tune work factors so as to impede attackers while providing acceptable user experience and scale.

Additionally, adaptive one-way functions do not effectively prevent reversal of common dictionary-based credentials (users with password ‘password’) regardless of user population size or salt usage.

Work Factor

Since resources are normally considered limited, a common rule of thumb for tuning the work factor (or cost) is to make protect() run as slow as possible without affecting the users' experience and without increasing the need for extra hardware over budget. So, if the registration and authentication's cases accept protect() taking up to 1 second, you can tune the cost so that it takes 1 second to run on your hardware. This way, it shouldn't be so slow that your users become affected, but it should also affect the attackers' attempt as much as possible.

While there is a minimum number of iterations recommended to ensure data safety, this value changes every year as technology improves. An example of the iteration count chosen by a well known company is the 10,000 iterations Apple uses for its iTunes passwords (using PBKDF2)[2](PDF file). However, it is critical to understand that a single work factor does not fit all designs. Experimentation is important.[*6]

Leverage Keyed functions

Keyed functions, such as HMACs, compute a one-way (irreversible) transform using a private key and given input. For example, HMACs inherit properties of hash functions including their speed, allowing for near instant verification. Key size imposes infeasible size- and/or space- requirements on compromise--even for common credentials (aka password = ‘password’). Designers protecting stored credentials with keyed functions:

  • Use a single “site-wide” key;
  • Protect this key as any private key using best practices;
  • Store the key outside the credential store (aka: not in the database);
  • Generate the key using cryptographically-strong pseudo-random data;
  • Do not worry about output block size (i.e. SHA-256 vs. SHA-512).

Example protect() pseudo-code follows:

return [salt] + HMAC-SHA-256([key], [salt] + [credential]);

Upholding security improvement over (solely) salted schemes relies on proper key management.

Design password storage assuming eventual compromise

The frequency and ease with which threats steal protected credentials demands “design for failure”. Having detected theft, a credential storage scheme must support continued operation by marking credential data compromised and engaging alternative credential validation workflows as follows:

  1. Protect the user’s account
    1. Invalidate authentication ‘shortcuts’ disallowing login without 2nd factors or secret questions.
    2. Disallow changes to user accounts such as editing secret questions and changing account multi-factor configuration settings.
  2. Load and use new protection scheme
    1. Load a new (stronger) protect(credential) function
    2. Include version information stored with form
    3. Set ‘tainted’/‘compromised’ bit until user resets credentials
    4. Rotate any keys and/or adjust protection function parameters (iter count)
    5. Increment scheme version number
  3. When user logs in:
    1. Validate credentials based on stored version (old or new); if old demand 2nd factor or secret answers
    2. Prompt user for credential change, apologize, & conduct out-of-band confirmation
    3. Convert stored credentials to new scheme as user successfully log in

References

Authors and Primary Editors

John Steven - john.steven[at]owasp.org

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets