Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][DISCUSSION] Argon2 Password Hash »

[RFC][DISCUSSION] Argon2 Password Hash

php.internals

Charles R. Portwood II

10 years ago
Hello Internals, Due to a couple issue with the original RFC's scope, the RFC for introducing Argon2 as an alternative hashing algorithm for the password_* functions was closed shortly after starting on Monday. The following details were adjusted. and I would appreciate your feedback before re-opening the vote. - The RFC scope was reduced to only cover inclusion in 7.2. This RFC no longer proposes changes to PASSWORD_DEFAULT in 7.4. - Argon2d is not suitable for password hashing, and has been removed to keep in line with the scope goals of the password_* functions. - The configure flag was changed to --with-argon2 to --with-password-argon2 to further clarify the scope of this RFC. Further rationale for these items is provided in the RFC itself. The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash. Thanks to those who emailed me directly to discuss the matter on Monday, and for your feedback on these changes. *Charles R. Portwood II*

Tom Worster

10 years ago
On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
> The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash.
Hi Charles, Thanks for doing this. I'm glad Argon2 is coming to PHP. You can have a longer voting period if you like, which I think would be a good idea. I think it's confusing to have two consts to identify the algorithm. I don't understand the analogy to PASSWORD_DEFAULT. If we only provide Argon2i, one const is easier. If we anticipate adding another Argon2 algo in the future that is not backward compatible with this one then I don't think we would want to change PASSWORD_ARGON2 to point to it. Finally, I wonder if it wouldn't be better if, for the time being, we do not provide default costs constants. Argon2 is new (as crypto algos go) and very early in a gradual introduction in deployments. And it is hard to use because of the three cost factors. Correctly tuning those for different machines is not yet a commonly-understood skill. (You even can find conflicting advice on how to tune Bcrypt's time factor.) If we offer default costs then it will appear, to some people, even those who know little about it beyond the name, as though deploying Argon2 is just a matter of using it with the defaults. I'm not sure this is a good idea. If, on the other hand, we omit the constants and require the $options argument then it discourages inexpert users. At the same time it encourages experimentation and understanding of the costs, among those who take an interest, which I think is just what we want. Those who want to use Argon2 are going to make special efforts to get the lib and enable it in PHP. So I don't think it's unreasonable to expect the early adopters to give some thought to the costs. Tom

Charles R. Portwood II

10 years ago
On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster <fsb@thefsb.org> wrote:
> On 8/5/16 8:47 AM, Charles R. Portwood II wrote: > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash >> >> . >> > > Hi Charles, > > Thanks for doing this. I'm glad Argon2 is coming to PHP. >
Hi Tom, Thanks for the feedback! You can have a longer voting period if you like, which I think would be
> a good idea.
Sounds good to me. I think it's confusing to have two consts to identify the algorithm. I
> don't understand the analogy to PASSWORD_DEFAULT. If we only provide > Argon2i, one const is easier. If we anticipate adding another Argon2 > algo in the future that is not backward compatible with this one then I > don't think we would want to change PASSWORD_ARGON2 to point to it.
I agree. Originally there was PASSWORD_ARGON2I and PASSWORD_ARGON2D, with PASSWORD_ARGON2 aliasing to PASSWORD_ARGON2I, but with Argon2d removed from scope the extra constant is now largely unnecessary. I don't anticipate Argon2 adding any additional algorithms at this point, given the spec and reference library is finalized. I think for clarity, PASSWORD_ARGON2I would be sufficient. What are your thoughts? Finally, I wonder if it wouldn't be better if, for the time being, we
> do not provide default costs constants. Argon2 is new (as crypto algos > go) and very early in a gradual introduction in deployments. And it is > hard to use because of the three cost factors. Correctly tuning those > for different machines is not yet a commonly-understood skill. (You > even can find conflicting advice on how to tune Bcrypt's time factor.) >
If, on the other hand, we omit the constants and require the $options
> argument then it discourages inexpert users. At the same time it > encourages experimentation and understanding of the costs, among those > who take an interest, which I think is just what we want.
The rationale for providing defaults is to ensure the password_* functions remain easy to use. Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) would become PASSWORD_DEFAULT, the end user's expectations would be that *password_hash($password, PASSWORD_DEFAULT)* just works, without needing to specify additional arguments. As the spec requires some minimum values to even work (and there's recommendations from the developers [1]), I think we should be providing defaults so that the algorithm works out of the box, though I agree they could be set to lower values. Note that the spec does specifically say that there is no "insecure" value for the memory and time cost attributes. If we wanted to drop it to the minimum recommend by the developers, the values would be: m_cost = 16 t_cost = 2 threads = 1 I'm open to other suggestions or alternatives though. Thanks, *Charles R. Portwood II* [1]: https://github.com/P-H-C/phc-winner-argon2/issues/144

Charles R. Portwood II

10 years ago
On Fri, Aug 5, 2016 at 9:49 AM, Charles R. Portwood II < charlesportwoodii@erianna.com> wrote:
> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster <fsb@thefsb.org> wrote: > >> On 8/5/16 8:47 AM, Charles R. Portwood II wrote: >> >> The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash >>> >>> . >>> >> >> Hi Charles, >> >> Thanks for doing this. I'm glad Argon2 is coming to PHP. > > > As the spec requires some minimum values to even work (and there's > recommendations from the developers [1]), I think we should be providing > defaults so that the algorithm works out of the box, though I agree they > could be set to lower values. Note that the spec does specifically say that > there is no "insecure" value for the memory and time cost attributes. If we > wanted to drop it to the minimum recommend by the developers, the values > would be: > > m_cost = 16 > t_cost = 2 > threads = 1 > > I'm open to other suggestions or alternatives though. > > Thanks, > *Charles R. Portwood II* > > [1]: https://github.com/P-H-C/phc-winner-argon2/issues/144 > >
For clarity, a memory cost of 16 implies 65536 KiB, or 64 MiB of memory. The only difference between the values recommended by the developers, and the cost outlined in the RFC is that the t_cost is set to 3. *Charles R. Portwood II*

Ryan Pallas

10 years ago
On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II < charlesportwoodii@erianna.com> wrote:
> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster <fsb@thefsb.org> wrote: > > > On 8/5/16 8:47 AM, Charles R. Portwood II wrote: > > Finally, I wonder if it wouldn't be better if, for the time being, we > > do not provide default costs constants. Argon2 is new (as crypto algos > > go) and very early in a gradual introduction in deployments. And it is > > hard to use because of the three cost factors. Correctly tuning those > > for different machines is not yet a commonly-understood skill. (You > > even can find conflicting advice on how to tune Bcrypt's time factor.) > > > > > If, on the other hand, we omit the constants and require the $options > > argument then it discourages inexpert users. At the same time it > > encourages experimentation and understanding of the costs, among those > > who take an interest, which I think is just what we want. > > > The rationale for providing defaults is to ensure the password_* functions > remain easy to use. Assuming that at some point PASSWORD_ARGON2I (or any > new algorithm) would become PASSWORD_DEFAULT, the end user's expectations > would be that *password_hash($password, PASSWORD_DEFAULT)* just works, > without needing to specify additional arguments. >
I think this is the most important part to consider. If you make $options required for this algo, then making this algo the PASSWORD_DEFAULT would mean that its a backwards incompatible change, because now all calls to password_hash($password, PASSWORD_DEFAULT) would need to be updated to use an older constant or pass in $options which I think totally defeats the purpose of the password_hash API. Please keep it so that defaults will work, but $options is available for tuning as that's how the feature currently works.

Tom Worster

10 years ago
On 8/5/16, 11:08 AM, "Ryan Pallas" <derokorian@gmail.com> wrote:
>Please keep it so that defaults will work, but $options is available for >tuning as that's how the feature currently works.
My suggestion doesn't affect that. I agree that password_hash($password, PASSWORD_DEFAULT) should always "just work". Instead, I think there should be an interim status, before changing PASSWORD_DEFAULT, in which password_hash($password, PASSWORD_ARGON2I) requires $options. Reasons given in my first reply. There is no hurry to change PASSWORD_DEFAULT, afaik. Tom

Charles R. Portwood II

10 years ago
On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas <derokorian@gmail.com> wrote:
> > > I think this is the most important part to consider. If you make $options > required for this algo, then making this algo the PASSWORD_DEFAULT would > mean that its a backwards incompatible change, because now all calls to > password_hash($password, PASSWORD_DEFAULT) would need to be updated to use > an older constant or pass in $options which I think totally defeats the > purpose of the password_hash API. > > Please keep it so that defaults will work, but $options is available for > tuning as that's how the feature currently works. >
> The rationale for providing defaults is to ensure the password_* >> functions remain easy to use. > >
I understand. I was actually suggesting that we deliberately make it
> harder to use!
Assuming that at some point PASSWORD_ARGON2I (or any new algorithm)
>> would become PASSWORD_DEFAULT, the end user's expectations would be that >> password_hash($password, PASSWORD_DEFAULT) just works, without needing to >> specify additional arguments. > >
I agree entirely. I'm not against introducing default cost constants. I am
> instead proposing we allow a period of time after introduction of Argon2 > into PHP before deciding what the default costs should be and define the > constants at the same time as setting PASSWORD_DEFAULT = PASSWORD_ARGON2I, > or possibly before.
> Please reread my previous message for the reasons behind this (odd, I > admit) idea.
Hi Tom, I understand what you're saying. Ryan said it a bit more clearly than I did, making the options required causes backwards-incompatible changes to the password_hash API. That's my real reservation behind not providing defaults. A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = PASSWORD_DEFAULT). If the supplied constants need to be changed for that, I think that would be the time to do so. I think for now something needs to be provided to ensure the password_hash API doesn't change. On Fri, Aug 5, 2016 at 11:29 AM, Niklas Keller <me@kelunik.com> wrote:
> > Hi Charles, > > I'd prefer `memory_cost` and `time_cost` over `m_cost` and `t_cost`. Do we > have any reason to use the shorter but less readable names here? > > Regards, Niklas >
'm_cost' and 't_cost' is what is used in the reference library. Someone looking at the reference material would see those names. Thanks, *Charles R. Portwood II*

Tom Worster

10 years ago
On 8/5/16, 12:36 PM, "Charles R. Portwood II" <charlesportwoodii@ethreal.net on behalf of charlesportwoodii@erianna.com> wrote:
>I understand what you're saying. Ryan said it a bit more clearly than I >did, making the options required causes backwards-incompatible changes to >the password_hash API. That's my real reservation behind not providing >defaults. > >A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = >PASSWORD_DEFAULT). If the supplied constants need to be changed for that, >I think that would be the time to do so. I think for now something needs >to be provided to ensure the password_hash API doesn't change.
I can understand an argument that it's too much to expect a user to provide an options array when using Argon2. But I don't understand how my suggestion breaks BC. In my idea, a future RFC would propose default cost constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on those constants so they would need to be defined before changing PASSWORD_DEFAULT or at the same time. So... password_hash('password', PASSWORD_DEFAULT) will always work. password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is introduced in your proposal, but has to wait for another future RFC in my suggested change. password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. How does a BC break happen? Tom

Charles R. Portwood II

10 years ago
On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <fsb@thefsb.org> wrote:
> > I can understand an argument that it's too much to expect a user to > provide an options array when using Argon2. But I don't understand how my > suggestion breaks BC. In my idea, a future RFC would propose default cost > constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on those > constants so they would need to be defined before changing > PASSWORD_DEFAULT or at the same time. So... > > password_hash('password', PASSWORD_DEFAULT) will always work. > > password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is > introduced in your proposal, but has to wait for another future RFC in my > suggested change. > > password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. > > How does a BC break happen? > > Tom >
Hi Tom, It breaks the API in the interim between this RFC and a potential future one. The $options parameter for both password_hash and password_needs_rehash is optional. Making it required for one algorithm but not another changes the API's for both methods. The expectations outlined in the original password_hash RFC make the third parameter for tuning the algorithm, not for making the algorithm work. Without default values, both password_hash and password_needs_rehash would fail unless the costs are provided. Hi Niklas, People knowing the reference library will probably recognize `memory_cost`
> and `time_cost`, but this is a simple API targeted on a large audience. > Most users of it won't know the reference library's internals.
If that's going to be easier for people I'm all for it.

Lauri Kenttä

10 years ago
On 2016-08-05 21:20, Charles R. Portwood II wrote:
> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <fsb@thefsb.org> wrote: >> >> I can understand an argument that it's too much to expect a user to >> provide an options array when using Argon2. But I don't understand how >> my >> suggestion breaks BC. In my idea, a future RFC would propose default >> cost >> constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on >> those >> constants so they would need to be defined before changing >> PASSWORD_DEFAULT or at the same time. So... >> >> password_hash('password', PASSWORD_DEFAULT) will always work. >> >> password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is >> introduced in your proposal, but has to wait for another future RFC in >> my >> suggested change. >> >> password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. >> >> How does a BC break happen? >> >> Tom >> > > Hi Tom, > > It breaks the API in the interim between this RFC and a potential > future > one. The $options parameter for both password_hash and > password_needs_rehash is optional. Making it required for one algorithm > but > not another changes the API's for both methods. The expectations > outlined > in the original password_hash RFC make the third parameter for tuning > the > algorithm, not for making the algorithm work. Without default values, > both > password_hash and password_needs_rehash would fail unless the costs are > provided. >
I think it's very important to provide some kind of default parameters. We have password_needs_rehash for the exact reason that we can later change the defaults if they are not good enough (anymore). If the defaults are not set, people will have to invent their own parameters, which may be good or very bad. These parameters will not be automatically updated with future versions of PHP. There is nothing to lose from setting some sane defaults. There is nothing to gain from NOT setting the defaults. About the memory requirements: setting the memory cost too high may limit using this algorithm in many inexpensive shared web hosting services, which may have default PHP memory limit as low as 128 MB or 256 MB.
-- Lauri Kenttä

Niklas Keller

10 years ago
2016-08-05 22:51 GMT+02:00 Lauri Kenttä <lauri.kentta@gmail.com>:
> On 2016-08-05 21:20, Charles R. Portwood II wrote: > >> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <fsb@thefsb.org> wrote: >> >>> >>> I can understand an argument that it's too much to expect a user to >>> provide an options array when using Argon2. But I don't understand how my >>> suggestion breaks BC. In my idea, a future RFC would propose default cost >>> constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on those >>> constants so they would need to be defined before changing >>> PASSWORD_DEFAULT or at the same time. So... >>> >>> password_hash('password', PASSWORD_DEFAULT) will always work. >>> >>> password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is >>> introduced in your proposal, but has to wait for another future RFC in my >>> suggested change. >>> >>> password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. >>> >>> How does a BC break happen? >>> >>> Tom >>> >>> >> Hi Tom, >> >> It breaks the API in the interim between this RFC and a potential future >> one. The $options parameter for both password_hash and >> password_needs_rehash is optional. Making it required for one algorithm >> but >> not another changes the API's for both methods. The expectations outlined >> in the original password_hash RFC make the third parameter for tuning the >> algorithm, not for making the algorithm work. Without default values, both >> password_hash and password_needs_rehash would fail unless the costs are >> provided. >> >> > I think it's very important to provide some kind of default parameters. > We have password_needs_rehash for the exact reason that we can later > change the defaults if they are not good enough (anymore). > > If the defaults are not set, people will have to invent their own > parameters, which may be good or very bad. These parameters will not be > automatically updated with future versions of PHP. >
We should definitely provide defaults.
> There is nothing to lose from setting some sane defaults. > There is nothing to gain from NOT setting the defaults. > > About the memory requirements: setting the memory cost too high may limit > using this algorithm in many inexpensive shared web hosting services, > which may have default PHP memory limit as low as 128 MB or 256 MB.
Setting the memory limit too high could also result in overall memory exhaustion with many concurrent login attempts.

Charles R. Portwood II

10 years ago
On Sat, Aug 6, 2016 at 6:09 AM, Niklas Keller <me@kelunik.com> wrote:
> 2016-08-05 22:51 GMT+02:00 Lauri Kenttä <lauri.kentta@gmail.com>: > >> On 2016-08-05 21:20, Charles R. Portwood II wrote: >> >>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <fsb@thefsb.org> wrote: >>> >>>> >>>> I can understand an argument that it's too much to expect a user to >>>> provide an options array when using Argon2. But I don't understand how >>>> my >>>> suggestion breaks BC. In my idea, a future RFC would propose default >>>> cost >>>> constants. Changing PASSWORD_DEFAULT to PASSWORD_ARGON2I depends on >>>> those >>>> constants so they would need to be defined before changing >>>> PASSWORD_DEFAULT or at the same time. So... >>>> >>>> password_hash('password', PASSWORD_DEFAULT) will always work. >>>> >>>> password_hash('password', PASSWORD_ARGON2I) works as soon as Argon2 is >>>> introduced in your proposal, but has to wait for another future RFC in >>>> my >>>> suggested change. >>>> >>>> password_hash('password', PASSWORD_ARGON2I, [costs]) will always work. >>>> >>>> How does a BC break happen? >>>> >>>> Tom >>>> >>>> >>> Hi Tom, >>> >>> It breaks the API in the interim between this RFC and a potential future >>> one. The $options parameter for both password_hash and >>> password_needs_rehash is optional. Making it required for one algorithm >>> but >>> not another changes the API's for both methods. The expectations outlined >>> in the original password_hash RFC make the third parameter for tuning the >>> algorithm, not for making the algorithm work. Without default values, >>> both >>> password_hash and password_needs_rehash would fail unless the costs are >>> provided. >>> >>> >> I think it's very important to provide some kind of default parameters. >> We have password_needs_rehash for the exact reason that we can later >> change the defaults if they are not good enough (anymore). >> >> If the defaults are not set, people will have to invent their own >> parameters, which may be good or very bad. These parameters will not be >> automatically updated with future versions of PHP. >> > > We should definitely provide defaults. > > >> There is nothing to lose from setting some sane defaults. >> There is nothing to gain from NOT setting the defaults. >> >> About the memory requirements: setting the memory cost too high may limit >> using this algorithm in many inexpensive shared web hosting services, >> which may have default PHP memory limit as low as 128 MB or 256 MB. > > > Setting the memory limit too high could also result in overall memory > exhaustion with many concurrent login attempts. >
Hi, Absolutely. What are your thoughts on the following cost factors? time_cost = 3 memory_cost = 12 threads = 1 The reference library provides a CLI program where these values are listed [1]. A memory_cost factor of 12 would be 4 MiB. Thanks, *Charles R. Portwood II* [1]: https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27

Tom Worster

10 years ago
On 8/5/16, 2:20 PM, "Charles R. Portwood II" <charlesportwoodii@ethreal.net on behalf of charlesportwoodii@erianna.com> wrote:
>It breaks the API in the interim between this RFC and a potential future >one. The $options parameter for both password_hash and >password_needs_rehash is optional. Making it required for one algorithm >but not another changes the API's for both methods. The expectations >outlined in the original password_hash RFC make the third parameter for >tuning the algorithm, not for making the algorithm work. Without default >values, both password_hash and password_needs_rehash would fail unless >the costs are provided.
OK. I misunderstood what qualifies as "broken". Looks most like most people want to set default costs right away so I'll leave it here. As for choosing the right default values for PHP, what are the criteria? Tom

Niklas Keller

10 years ago
2016-08-05 18:36 GMT+02:00 Charles R. Portwood II < charlesportwoodii@erianna.com>:
> On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas <derokorian@gmail.com> wrote: > > > > > > I think this is the most important part to consider. If you make $options > > required for this algo, then making this algo the PASSWORD_DEFAULT would > > mean that its a backwards incompatible change, because now all calls to > > password_hash($password, PASSWORD_DEFAULT) would need to be updated to > use > > an older constant or pass in $options which I think totally defeats the > > purpose of the password_hash API. > > > > Please keep it so that defaults will work, but $options is available for > > tuning as that's how the feature currently works. > > > > > > > The rationale for providing defaults is to ensure the password_* > >> functions remain easy to use. > > > > > > I understand. I was actually suggesting that we deliberately make it > > harder to use! > > > Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) > >> would become PASSWORD_DEFAULT, the end user's expectations would be that > >> password_hash($password, PASSWORD_DEFAULT) just works, without needing > to > >> specify additional arguments. > > > > > > I agree entirely. I'm not against introducing default cost constants. I am > > instead proposing we allow a period of time after introduction of Argon2 > > into PHP before deciding what the default costs should be and define the > > constants at the same time as setting PASSWORD_DEFAULT = > PASSWORD_ARGON2I, > > or possibly before. > > > > Please reread my previous message for the reasons behind this (odd, I > > admit) idea. > > > Hi Tom, > > I understand what you're saying. Ryan said it a bit more clearly than I > did, making the options required causes backwards-incompatible changes to > the password_hash API. That's my real reservation behind not providing > defaults. > > A separate RFC would be needed for 7.4 to make PASSWORD_ARGON2I = > PASSWORD_DEFAULT). If the supplied constants need to be changed for that, I > think that would be the time to do so. I think for now something needs to > be provided to ensure the password_hash API doesn't change. > > On Fri, Aug 5, 2016 at 11:29 AM, Niklas Keller <me@kelunik.com> wrote: > > > > Hi Charles, > > > > I'd prefer `memory_cost` and `time_cost` over `m_cost` and `t_cost`. Do > we > > have any reason to use the shorter but less readable names here? > > > > Regards, Niklas > > > > 'm_cost' and 't_cost' is what is used in the reference library. Someone > looking at the reference material would see those names.
People knowing the reference library will probably recognize `memory_cost` and `time_cost`, but this is a simple API targeted on a large audience. Most users of it won't know the reference library's internals. Regards, Niklas

Tom Worster

10 years ago
On 8/5/16, 10:49 AM, "Charles R. Portwood II" <charlesportwoodii@ethreal.net on behalf of charlesportwoodii@erianna.com> wrote:
>I think for clarity, PASSWORD_ARGON2I would be sufficient. What are your >thoughts?
Looks good.
>The rationale for providing defaults is to ensure the password_* >functions remain easy to use.
I understand. I was actually suggesting that we deliberately make it harder to use!
> Assuming that at some point PASSWORD_ARGON2I (or any new algorithm) >would become PASSWORD_DEFAULT, the end user's expectations would be that >password_hash($password, PASSWORD_DEFAULT) just works, without needing to >specify additional arguments.
I agree entirely. I'm not against introducing default cost constants. I am instead proposing we allow a period of time after introduction of Argon2 into PHP before deciding what the default costs should be and define the constants at the same time as setting PASSWORD_DEFAULT = PASSWORD_ARGON2I, or possibly before. Please reread my previous message for the reasons behind this (odd, I admit) idea. Tom

Niklas Keller

10 years ago
2016-08-05 14:47 GMT+02:00 Charles R. Portwood II < charlesportwoodii@erianna.com>:
> Hello Internals, > > Due to a couple issue with the original RFC's scope, the RFC for > introducing Argon2 as an alternative hashing algorithm for the password_* > functions was closed shortly after starting on Monday. > > The following details were adjusted. and I would appreciate your feedback > before re-opening the vote. > > - The RFC scope was reduced to only cover inclusion in 7.2. This RFC no > longer proposes changes to PASSWORD_DEFAULT in 7.4. > - Argon2d is not suitable for password hashing, and has been removed to > keep in line with the scope goals of the password_* functions. > - The configure flag was changed to --with-argon2 to > --with-password-argon2 to further clarify the scope of this RFC. > > Further rationale for these items is provided in the RFC itself. > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash. > > Thanks to those who emailed me directly to discuss the matter on Monday, > and for your feedback on these changes. > > *Charles R. Portwood II* >
Hi Charles, I'd prefer `memory_cost` and `time_cost` over `m_cost` and `t_cost`. Do we have any reason to use the shorter but less readable names here? Regards, Niklas

Jared Williams

10 years ago
On Fri, 2016-08-05 at 07:47 -0500, Charles R. Portwood II wrote:
> Hello Internals, > > Due to a couple issue with the original RFC's scope, the RFC for > introducing Argon2 as an alternative hashing algorithm for the > password_* > functions was closed shortly after starting on Monday. > > The following details were adjusted. and I would appreciate your > feedback > before re-opening the vote. > >    - The RFC scope was reduced to only cover inclusion in 7.2. This > RFC no >    longer proposes changes to PASSWORD_DEFAULT in 7.4. >    - Argon2d is not suitable for password hashing, and has been > removed to >    keep in line with the scope goals of the password_* functions. >    - The configure flag was changed to --with-argon2 to >    --with-password-argon2 to further clarify the scope of this RFC. > > Further rationale for these items is provided in the RFC itself. > > The RFC is available at: https://wiki.php.net/rfc/argon2_password_has > h. > > Thanks to those who emailed me directly to discuss the matter on > Monday, > and for your feedback on these changes. > > *Charles R. Portwood II*
Argon2 also supports keyed hashes and associated data, but seen no mention of either. Jared

Charles R. Portwood II

10 years ago
> > Argon2 also supports keyed hashes and associated data, but seen no > mention of either. > Jared
Hi Jared, This is a design decision to prevent changing the PHP API. The Argon2 reference library exposes two ways of working with Argon2 hashes, we can either use the Argon2_Context struct, or pass our data directly to the argon2_hash/verify functions. The former is the only way to provided a hash key and associated data. Since password_hash doesn't expose the salt is generates, and since password_verify doesn't accept an array options, it would be impossible to verify Argon2 hashes created with a hash key and associated data without changing the PHP API for that function. *Charles R. Portwood II*