Difference between revisions of "Password Storage Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Use a modern hash algorithm)
m
Line 1: Line 1:
= DRAFT CHEAT SHEET - WORK IN PROGRESS =
 
 
 
= Introduction =
 
= Introduction =
  
This article is focused on providing guidance to storing a password in order to help prevent password theft. Too often passwords are stored as clear text. Thus the password can be read directly by the database’s administrator, super users or via data theft by SQL Injection. Database backup media is also vulnerable to password theft via password storage. It is recommended that you avoid storing the clear text password or an encrypted version of the password.
+
This article is focused on providing guidance to storing a password in order to help prevent password theft. Too often passwords are stored as clear text. Thus the password can be read directly by the database's administrator, super users or via data theft by SQL Injection. Database backup media is also vulnerable to password theft via password storage. It is recommended that you avoid storing the clear text password or an encrypted version of the password.
  
== Password Storage Rules ==
+
= Password Storage Rules =
  
Passwords are secrets. There is no reason to decrypt them under any circumstances. It is crucial that passwords are stored in a way that they can be *verified* but not *reversed* in any way, even by insiders. To accomplish this, store the salted hashed value of the password. Preferably use a different random salt for each password hash instead of a constant long salt.   
+
Passwords are secrets. There is no reason to decrypt them under any circumstances. It is crucial that passwords are stored in a way that they can be verified but not reversed in any way, even by insiders.   
  
=== Use a modern hash algorithm ===
+
=== Use a Modern Hash Algorithm ===
# SHA
+
# bcrypt
+
  
=== Use a long cryptographically random salt ===
+
Hashing or Digest algorithms are using the verify the integrity of data. These class of algorithms do not provide the ability to reverse the hash value to the original form. This is perfect for password storage since we wish to verify but not uncover the hashed value of password.
 +
 
 +
=== Use a Long Cryptographically Random Salt ===
  
 
If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password’s hash:
 
If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password’s hash:
 +
 
# Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of passwords the database is large.
 
# Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of passwords the database is large.
 
# An attacker can use a list of precomputed hashed (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.  
 
# An attacker can use a list of precomputed hashed (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.  
In order to solve these problems, a salt must be concatenated in front of the password before the digest operation.
 
  
A salt is a cryptographically random number of a fixed length. This salt must be different for each stored entry.  Since rainbow tables are already passing 24 characters, a salt of 24 bytes or longer is the recommended minimum length.
+
In order to solve these problems, a salt must be concatenated in front of the password before the digest operation. A salt is a cryptographically random number of a fixed length. This salt must be different for each stored entry.  Since rainbow tables are already passing 24 characters, a salt of 24 bytes or longer is the recommended minimum length.
  
 
=== Iterate the hash ===
 
=== Iterate the hash ===
  
 
To slow down the computation it is recommended to iterate 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 gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user. A minimum of 1000 operations is recommended in RSA PKCS5 standard in 2000, a value that should be doubled every 2 years.
 
To slow down the computation it is recommended to iterate 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 gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user. A minimum of 1000 operations is recommended in RSA PKCS5 standard in 2000, a value that should be doubled every 2 years.
 +
 +
=== Salt Isolation ===
 +
 +
One additional password storage defense mechanism involves storing the salt in a different location as the password hash. Use of the servers filesystem is one commonly used mechanism for salt isolation. This defense mechanism reduces the risk of password theft when a database backup file is stolen, since the salts will not be includes with the database data, which includes the password hash.
  
 
== References ==
 
== References ==
  
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 ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).
+
# 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 ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).
 +
# Much of this article came from the original password storage article here: [Hashing Java]].
  
 
{{Cheatsheet_Navigation}}
 
{{Cheatsheet_Navigation}}
  
 
[[Category:Cheatsheets]]
 
[[Category:Cheatsheets]]

Revision as of 20:16, 24 November 2011

Contents

Introduction

This article is focused on providing guidance to storing a password in order to help prevent password theft. Too often passwords are stored as clear text. Thus the password can be read directly by the database's administrator, super users or via data theft by SQL Injection. Database backup media is also vulnerable to password theft via password storage. It is recommended that you avoid storing the clear text password or an encrypted version of the password.

Password Storage Rules

Passwords are secrets. There is no reason to decrypt them under any circumstances. It is crucial that passwords are stored in a way that they can be verified but not reversed in any way, even by insiders.

Use a Modern Hash Algorithm

Hashing or Digest algorithms are using the verify the integrity of data. These class of algorithms do not provide the ability to reverse the hash value to the original form. This is perfect for password storage since we wish to verify but not uncover the hashed value of password.

Use a Long Cryptographically Random Salt

If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to choosing to only storing the password’s hash:

  1. Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can find a password very quickly especially if the number of passwords the database is large.
  2. An attacker can use a list of precomputed hashed (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.

In order to solve these problems, a salt must be concatenated in front of the password before the digest operation. A salt is a cryptographically random number of a fixed length. This salt must be different for each stored entry. Since rainbow tables are already passing 24 characters, a salt of 24 bytes or longer is the recommended minimum length.

Iterate the hash

To slow down the computation it is recommended to iterate 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 gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user. A minimum of 1000 operations is recommended in RSA PKCS5 standard in 2000, a value that should be doubled every 2 years.

Salt Isolation

One additional password storage defense mechanism involves storing the salt in a different location as the password hash. Use of the servers filesystem is one commonly used mechanism for salt isolation. This defense mechanism reduces the risk of password theft when a database backup file is stolen, since the salts will not be includes with the database data, which includes the password hash.

References

  1. Cryptographic framework for password hashing is described in PKCS #5 v2.1: Password-Based Cryptography Standard.
  2. Specific secure password hashing algorithms exist such as bcrypt, scrypt.
  3. Implementations of secure password hashing exist for PHP (phpass), ASP.NET (ASP.NET 2.0 Security Practices), Java (OWASP Hashing Java).
  4. Much of this article came from the original password storage article here: [Hashing Java]].

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets