rfc:password_registry

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:password_registry [2018/10/18 19:31]
pollita
rfc:password_registry [2018/12/25 13:07] (current)
cmb This RFC has already been implemented
Line 1: Line 1:
 ====== PHP RFC: Password Hashing Registry ====== ====== PHP RFC: Password Hashing Registry ======
-  * Version: ​0.1+  * Version: 1.0
   * Date: 2018-10-15   * Date: 2018-10-15
   * Author: Sara Golemon, pollita@php.net   * Author: Sara Golemon, pollita@php.net
-  * Status: ​Draft+  * Status: ​Implemented (PHP 7.4)
   * First Published at: http://​wiki.php.net/​rfc/​password_registry   * First Published at: http://​wiki.php.net/​rfc/​password_registry
  
Line 41: Line 41:
 The **get_info** method pointer allows adding entries to an array return value for the password_get_info() userspace command. ​ This function must return SUCCESS or FAILURE. The **get_info** method pointer allows adding entries to an array return value for the password_get_info() userspace command. ​ This function must return SUCCESS or FAILURE.
  
-The **valid** method pointer is the mechanism used for determining what algorithm handler is appropriate for a given hash string. ​ For example, only the **bcrypt** handler should return true for a hash string beginning with "​$2y$"​.+The **valid** method pointer is the mechanism used for determining what algorithm handler is appropriate for a given hash string. ​ For example, only the **bcrypt** handler should return true for a hash string beginning with "​$2y$"​.  This callback may be NULL if the name alone is sufficient to identify an algorithm. ​ For example, the bcrypt algorithm has a length check in addition to its name identifier.
  
 Because the registry is organized as an associative array, any attempt to re-register an already present password mechanism will result in a failure. Because the registry is organized as an associative array, any attempt to re-register an already present password mechanism will result in a failure.
Line 63: Line 63:
 ====== Minimizing impact to BC ====== ====== Minimizing impact to BC ======
  
-We could overload the **password_hash()** and **password_needs_rehash()** methods to accept integer values 0, 1, 2, and 3 to function as aliases for DEFAULT, BCRYPT, ARGIN2I, and ARGON2ID, respectively.+In order to minimize the impact of the above BC. we could overload the **password_hash()** and **password_needs_rehash()** methods to accept integer values 0, 1, 2, and 3 to function as aliases for DEFAULT, BCRYPT, ARGIN2I, and ARGON2ID, respectively.   Using an int would therefore work, but would produce a deprecation warning. ​ This is being presented as a separate vote below.
  
 ===== Extension Changes ===== ===== Extension Changes =====
Line 70: Line 70:
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
 7.next 7.next
- 
-===== Open Questions ===== 
-  * Should the registry support password hashing mechanisms defined in script code? (I don't think so, but feel free to disagree) 
  
 ===== Future Scope ===== ===== Future Scope =====
-Review ext/sodium to see if there are additional password hashing algorithms it may be appropriate to enable.+  * Review ext/sodium to see if there are additional password hashing algorithms it may be appropriate to enable
 +  * Consider exposing the registry to script code for the purpose of polyfill libraries.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
 Simple 50% +1, make the password hashing system extensible via internal-only registry. Simple 50% +1, make the password hashing system extensible via internal-only registry.
 +
 +<doodle title="​Make the password hashing system extensible via internal-only registry?"​ auth="​pollita"​ voteType="​single"​ closed="​true">​
 +   * Yes
 +   * No
 +</​doodle>​
 +
 +
 +Should the above poll pass, the following 50%+1 question asks if we should additionally provide the overloaded behavior described above in "​minimizing impact to BC".
 +
 +<doodle title="​Support integer constants 0-3 to password_hash() et. al. for BC" auth="​pollita"​ voteType="​single"​ closed="​true">​
 +   * Yes
 +   * No
 +</​doodle>​
 +
 +
 +Vote Open: 2018-11-06 17:00 UTC
 +
 +Vote Closes: 2018-11-20 17:00 UTC
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
Line 86: Line 102:
   * https://​github.com/​php/​php-src/​pull/​3609   * https://​github.com/​php/​php-src/​pull/​3609
  
 +===== Implementation =====
 +
 +  - Implementation:​ <​http://​git.php.net/?​p=php-src.git;​a=commit;​h=534df87c9e3c28001986e70844e0ad04e5708d3d>​
 +  - Documentation:​ to be done.
  
rfc/password_registry.1539891095.txt.gz · Last modified: 2018/10/18 19:31 by pollita