rfc:password_hash

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:password_hash [2012/09/04 14:13] – Open Voting ircmaxellrfc:password_hash [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Request for Comments: Adding simple password hashing API ====== ====== Request for Comments: Adding simple password hashing API ======
-  * Version: 1.3+  * Version: 1.4
   * Date: 2012-06-26   * Date: 2012-06-26
   * Author: Anthony Ferrara <ircmaxell@php.net>   * Author: Anthony Ferrara <ircmaxell@php.net>
-  * Status: Voting Opened+  * Status: Implemented
   * First Published at: http://wiki.php.net/rfc/password_hash   * First Published at: http://wiki.php.net/rfc/password_hash
  
Line 22: Line 22:
 ==== Why Do We Need A Simple API ==== ==== Why Do We Need A Simple API ====
  
-As recent attacks have shown, strong password hashing is something that the vast majority of PHP developers don't understand, or don't think is worth the effort. The current core implementations of strong password hashing using //crypt()// are actually fairly difficult to work with. The error states are difficult to check for (returning //*0// or //*1// on error). The salt format is difficult to generate as it uses a custom base64 alphabet (//.// instead of //+// and no padded //=//). Additionally, salts are reasonably difficult to generate randomly (not too difficult, but requires a fair bit of code). Additionally, checking the return when validating a password can expose the application to [[remote timing attacks|http://en.wikipedia.org/wiki/Timing_attack]].+As recent attacks have shown, strong password hashing is something that the vast majority of PHP developers don't understand, or don't think is worth the effort. The current core implementations of strong password hashing using //crypt()// are actually fairly difficult to work with. The error states are difficult to check for (returning //*0// or //*1// on error). The salt format is difficult to generate as it uses a custom base64 alphabet (//.// instead of //+// and no padded //=//). Additionally, salts are reasonably difficult to generate randomly (not too difficult, but requires a fair bit of code). Additionally, checking the return when validating a password can expose the application to [[http://en.wikipedia.org/wiki/Timing_attack|remote timing attacks]].
  
 By providing a simple API that can be called, which takes care of all of those issues for you, hopefully more projects and developers will be able to use secure password hashing.  By providing a simple API that can be called, which takes care of all of those issues for you, hopefully more projects and developers will be able to use secure password hashing. 
- 
 ===== Common Misconceptions ===== ===== Common Misconceptions =====
  
-==== Salts Need To Be Cryptographically Secure ====+==== Salts Need To Be True Random ====
  
-Salts exist for a single reason: To make it so that any time (CPU effort) spent cracking a single password hash cannot be amortized across multiple hashes. That means that attacking a single password hash will have no impact on the time it will take attacking another hash. Based on that reason, salts only need to be unique in a system. There is no requirement for them to be cryptographically secure.+Salts exist for a single reason: To make it so that any time (CPU effort) spent cracking a single password hash cannot be amortized across multiple hashes. That means that attacking a single password hash will have no impact on the time it will take attacking another hash. Based on that reason, salts only need to be statistically globally unique. There is no requirement for them to be true random (as you would need for an encryption key). This means that ///dev/urandom// is acceptable, while //mt_rand()// and //rand()// are not (except as fallbacks).
  
 ==== Hash(password + salt) Is Fine ==== ==== Hash(password + salt) Is Fine ====
Line 52: Line 51:
  
   * //PASSWORD_BCRYPT = 1// - Create new password hashes using the //CRYPT_BLOWFISH// algorithm   * //PASSWORD_BCRYPT = 1// - Create new password hashes using the //CRYPT_BLOWFISH// algorithm
-  * //PASSWORD_DEFAULT = PASSWORD_BCRYPT// - The default algorithm to use for hashing if no algorithm is provided. This can change in future releases if a new, stronger hashing algorithm (such as //scrypt// is supported).+  * //PASSWORD_DEFAULT = PASSWORD_BCRYPT// - The default algorithm to use for hashing if no algorithm is provided. This can change in future releases when a new, stronger hashing algorithm (such as //scrypt//is supported.
  
 ==== Supported Algorithms ==== ==== Supported Algorithms ====
Line 404: Line 403:
  
 <doodle  <doodle 
-title="Should the simplified password hashing API indicated here be included in master?" auth="ircmaxell" voteType="single" closed="False">+title="Should the simplified password hashing API indicated here be included in master?" auth="ircmaxell" voteType="single" closed="true">
    * Yes    * Yes
    * No    * No
Line 422: Line 421:
   * 1.2 - Removed //password_make_salt()// function from proposal   * 1.2 - Removed //password_make_salt()// function from proposal
   * 1.3 - Open Voting   * 1.3 - Open Voting
 +  * 1.4 - Close Voting - Moving To Accepted
 +  * 1.5 - Implemented!
 +  * 1.5.1 - Fine tune wording of "Cryptographically Secure Salt Requirement"
rfc/password_hash.1346767987.txt.gz · Last modified: 2017/09/22 13:28 (external edit)