|
|
| (86 intermediate revisions by 13 users not shown) |
| Line 1: |
Line 1: |
| − | = DRAFT CHEAT SHEET - 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 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.
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html Password Storage Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | == 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.
| |
| − | | |
| − | === Use a modern hash ===
| |
| − | ==== SHA ====
| |
| − | ==== bcrypt ====
| |
| − | | |
| − | === 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:
| |
| − | # 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.
| |
| − | 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 ===
| |
| − | | |
| − | == 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]).
| |
| − | | |
| − | {{Cheatsheet_Navigation}}
| |
| − | | |
| − | [[Category:Cheatsheets]]
| |
