rfc:argon2_password_hash_enhancements

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
Next revisionBoth sides next revision
rfc:argon2_password_hash_enhancements [2018/01/17 17:30] charlesportwoodiirfc:argon2_password_hash_enhancements [2018/06/06 16:30] charlesportwoodii
Line 1: Line 1:
 ====== PHP RFC: Argon2 Password Hash Enhancements ====== ====== PHP RFC: Argon2 Password Hash Enhancements ======
-  * Version: 0.1+  * Version: 0.2
   * Date: 2018-01-11   * Date: 2018-01-11
   * Author: Charles R. Portwood II <charlesportwoodii@erianna.com>   * Author: Charles R. Portwood II <charlesportwoodii@erianna.com>
-  * Status: Draft+  * Status: Voting
   * First Published at: http://wiki.php.net/rfc/argon2_password_hash_enhancements   * First Published at: http://wiki.php.net/rfc/argon2_password_hash_enhancements
  
Line 103: Line 103:
 Argon2 exposes via the _ctx API (which currently isn't used by this implementation) a way to inject a separate secret key, which can be used to further strength the resulting Argon2 hashes. Argon2 exposes via the _ctx API (which currently isn't used by this implementation) a way to inject a separate secret key, which can be used to further strength the resulting Argon2 hashes.
  
-There has been some discussion of this both within bugs.php.net (https://bugs.php.net/bug.php?id=753880) and within the reference library (https://github.com/P-H-C/phc-winner-argon2/issues/222).+There has been some discussion of this both within bugs.php.net (https://bugs.php.net/bug.php?id=75388) and within the reference library (https://github.com/P-H-C/phc-winner-argon2/issues/222).
  
 I do not feel including the secret parameter within the password_hashing API is appropriate for the following reasons: I do not feel including the secret parameter within the password_hashing API is appropriate for the following reasons:
Line 122: Line 122:
 PHP already knows if Argon2id is available when compiling PHP. As Argon2id is a //new// algorithm however, we need to decide how --with-password-argon2[=DIR] should behave. Should it include both Argon2i and Argon2id? Should we force a minimum reference library version? Or should we introduce a new configure flag for this new function? PHP already knows if Argon2id is available when compiling PHP. As Argon2id is a //new// algorithm however, we need to decide how --with-password-argon2[=DIR] should behave. Should it include both Argon2i and Argon2id? Should we force a minimum reference library version? Or should we introduce a new configure flag for this new function?
  
-=== Force lib >= 20161029, making --with-password-argon2 flag is inclusive of both Argon2i and Argon2id ===+This RFC proposes the first option, of forcing lib >= 20161029 during the configure stage making the --with-password-argon2 flag inclusive of both Argon2i and Argon2id. 
 + 
 +=== Force lib >= 20161029, making the --with-password-argon2 flag inclusive of both Argon2i and Argon2id ===
  
 In this scenario we would force the library version to be >= 20161029. From configure, –with-password-argon2[=DIR] m4 would fail if Argon2id wasn't available, and prompt the user to upgrade their library version. The existing implementation already performs a check for the availability of Argon2id due to ABI differences with argon2_encoded() in different library version. In this scenario we would force the library version to be >= 20161029. From configure, –with-password-argon2[=DIR] m4 would fail if Argon2id wasn't available, and prompt the user to upgrade their library version. The existing implementation already performs a check for the availability of Argon2id due to ABI differences with argon2_encoded() in different library version.
  
-This change would be the easiest, and most forward thinking since Argon2id is the recommended ietf algorithm. Additionally it would ensure that PHP stays up to date with the reference library. +This change would be the easiest, and most forward thinking since Argon2id is the recommended ITEF algorithm. Additionally it would ensure that PHP stays up to date with the reference library. 
  
 This would require users on Stretch however to manually compile and upgrade to lib >= 20161029. The affect on Windows users is minimal as we're already providing ref/lib's for Windows compilation. Buster (testing) and Sid (unstable) are scheduled with 20161029. This would require users on Stretch however to manually compile and upgrade to lib >= 20161029. The affect on Windows users is minimal as we're already providing ref/lib's for Windows compilation. Buster (testing) and Sid (unstable) are scheduled with 20161029.
Line 138: Line 140:
 As m4 already knows if Argon2id is available in the lib, the functionality in PHP would be enabled for Argon2id if and only if Argon2id was available in the library.  As m4 already knows if Argon2id is available in the lib, the functionality in PHP would be enabled for Argon2id if and only if Argon2id was available in the library. 
  
-This approach is offered as a fallback incase option (1) is not selected. The greatest failings with this option are that userland checks would need to be performed for PASSWORD_ARGON2I and PASSWORD_ARGON2ID to determine what is actually available. Disabling certain features based upon a library version muddles what was actually available since phpinfo() doesn't report the compiled library version. Between the userland checks and the inability to easily identify what features are actually available likely disqualify this option.+This approach is offered as a fallback in case option (1) is not selected. The greatest failings with this option are that user land checks would need to be performed for PASSWORD_ARGON2I and PASSWORD_ARGON2ID to determine what is actually available. Disabling certain features based upon a library version muddles what was actually available since phpinfo() doesn't report the compiled library version. Between the user land checks and the inability to easily identify what features are actually available likely disqualify this option. 
 + 
 +This RFC does not propose this option.
  
 === Introduce a new configure argument --with-password-argon2id === === Introduce a new configure argument --with-password-argon2id ===
  
-A third, less desirable solution would be to explicitly use a new configure flag --with-password-argon2id, and run the Argon2id checks only if this flag is declared. This flag would be in addition to --with-password-argon2. This behavior is award however. As a end user I would expected --with-password-argon2 is inclusive of any valid Argon2 algorithm. Moreover as the --with-password-argon2 check already determines if Argon2id is available, it may introduce more complexity than desired in the implementation. This is more visible than option (2) but still suffers from the same core problems.+A third, less desirable solution would be to explicitly use a new configure flag --with-password-argon2id, and run the Argon2id checks only if this flag is declared. This flag would be in addition to --with-password-argon2.  As a end user I would expected --with-password-argon2 to be inclusive of any Argon2 algorithm. Moreover as the --with-password-argon2 check already determines if Argon2id is available, it may introduce more complexity than desired in the implementation. This is more visible than option (2) but still suffers from the same core problems.
  
 +This RFC does not propose this option.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
  
-Vote YES to include Argon2id as an alternative to Argon2i within the password_* functions in 7.3. A 50%+1 majority should be sufficient.+Vote YES to include Argon2id as an alternative to Argon2i within the password_* functions in 7.3. 
 + 
 +A 50%+1 majority should be sufficient. 
 + 
 +<doodle title="argon2_password_hash_enhancements" auth="charlesportwoodii" voteType="single" closed="false"> 
 +   * Yes 
 +   * No 
 +</doodle> 
  
-Voting will be open for 2 weeks.+Voting will be open for 2 weeks (6/6/2018-6/18/2018)
  
 ===== Implementation ===== ===== Implementation =====
Line 169: Line 182:
  
   - 2018-01-11: 0.1 Initial RFC draft   - 2018-01-11: 0.1 Initial RFC draft
 +  - 2018-02-01: Opened discussion to internals
 +  - 2018-05-22: Re-submitted to internals for discussion
 +  - 2018-06-06: Opened for Vote
rfc/argon2_password_hash_enhancements.txt · Last modified: 2018/10/10 11:17 by neufeind