rfc:argon2_password_hash_enhancements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:argon2_password_hash_enhancements [2018/01/11 19:27] – charlesportwoodii | rfc:argon2_password_hash_enhancements [2018/06/06 16:25] – Opened to Voting 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 < | * Author: Charles R. Portwood II < | ||
- | * Status: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
Line 10: | Line 10: | ||
==== Overview of Argon2 and Argon2id specific algorithm ==== | ==== Overview of Argon2 and Argon2id specific algorithm ==== | ||
- | Argon2 has one primary variant: Argon2id, and two supplementary | + | |
+ | Argon2 has three variants: | ||
Line 37: | Line 38: | ||
</ | </ | ||
- | Behaviorally, | + | This implementation will act identical to the Argon2i implementation in that it will accept the same cost variables introduces in the Argon2i RFC. |
<code php> | <code php> | ||
Line 44: | Line 45: | ||
</ | </ | ||
- | Functionally, | + | Argon2id will use the same default cost measures as the Argon2i implementation. |
==== Changes to password_verify() ==== | ==== Changes to password_verify() ==== | ||
Line 88: | Line 89: | ||
==== Why was Argon2id not included in the original RFC? ==== | ==== Why was Argon2id not included in the original RFC? ==== | ||
- | The original Argon2i password_hash RFC https:// | + | The original Argon2i password_hash RFC https:// |
- | That being said, a late addition to the implementation include support for reference library | + | Argon2id was not introduced into the reference library |
+ | That being said, a late addition to the implementation include support for reference library 20161029 since it changed the argon2_encoded() method. This change was made due to uncertainty about what reference library implementation would land in Debian Stretch/ | ||
+ | |||
+ | ==== Should we deprecate Argon2i? ==== | ||
+ | |||
+ | No, I do not believe we should deprecate Argon2i from password_*. Argon2i remains a perfectly secure and reasonable choice for password hashing. Argon2id simply provides better resistance to some form of attacks at the cost of time-memory tradeoffs. Argon2id is recommended at this point simply because it provides a blend of Argon2i and Argon2d. The existence of Argon2id does not negate the benefits of Argon2i. | ||
+ | |||
+ | ==== Add Secret Parameter? ==== | ||
+ | |||
+ | 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:// | ||
+ | |||
+ | I do not feel including the secret parameter within the password_hashing API is appropriate for the following reasons: | ||
+ | - Per the Argon2 documentation, | ||
+ | - The Argon2 spec doesn' | ||
+ | - More complex behaviors are available in Libsodium (which is now a core PHP extension). | ||
+ | |||
+ | ==== Custom Salt Value? ==== | ||
+ | |||
+ | The salt option was deprecated from password_hash in 7.0. I do not feel it is appropriate to re-introduce it again. Moreover, the addition of a custom salt attribute was rejected in the original Argon2i RFC. | ||
==== Configuring // Support for Argon2 >= 20161029 ==== | ==== Configuring // Support for Argon2 >= 20161029 ==== | ||
Line 101: | 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, --with-password-argon2 | + | 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, | ||
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 | + | This change would be the easiest, and most forward thinking since Argon2id is the recommended |
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/ | 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/ | ||
Line 117: | 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 | + | This approach is offered as a fallback |
+ | |||
+ | This RFC does not propose | ||
=== 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, | + | A third, less desirable solution would be to explicitly use a new configure flag --with-password-argon2id, |
+ | 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=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
- | Voting will be open for 2 weeks. | + | Voting will be open for 2 weeks (6/ |
===== Implementation ===== | ===== Implementation ===== | ||
Line 141: | Line 175: | ||
- https:// | - https:// | ||
- https:// | - https:// | ||
- | - https:// | + | - https:// |
- | - https:// | + | - https:// |
- https:// | - https:// | ||
Line 148: | 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-05: Opened for Vote |
rfc/argon2_password_hash_enhancements.txt · Last modified: 2018/10/10 11:17 by neufeind