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 toPASSWORD_DEFAULTin 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
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
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
On Fri, Aug 5, 2016 at 9:49 AM, Charles R. Portwood II <
charlesportwoodii@erianna.com> 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 = 1I'm open to other suggestions or alternatives though.
Thanks,
Charles R. Portwood II
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
On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II <
charlesportwoodii@erianna.com> 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.
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
I think this is the most important part to consider. If you make $options
required for this algo, then making this algo thePASSWORD_DEFAULTwould
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 settingPASSWORD_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.
Hi Charles,
I'd prefer
memory_costandtime_costoverm_costandt_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
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
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. ChangingPASSWORD_DEFAULTto PASSWORD_ARGON2I depends on those
constants so they would need to be defined before changing
PASSWORD_DEFAULTor 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.
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. ChangingPASSWORD_DEFAULTto PASSWORD_ARGON2I depends on
those
constants so they would need to be defined before changing
PASSWORD_DEFAULTor 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ä
2016-08-05 22:51 GMT+02:00 Lauri Kenttä lauri.kentta@gmail.com:
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. ChangingPASSWORD_DEFAULTto PASSWORD_ARGON2I depends on those
constants so they would need to be defined before changing
PASSWORD_DEFAULTor 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.
2016-08-05 22:51 GMT+02:00 Lauri Kenttä lauri.kentta@gmail.com:
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. ChangingPASSWORD_DEFAULTto PASSWORD_ARGON2I depends on
those
constants so they would need to be defined before changing
PASSWORD_DEFAULTor 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
Absolutely. What are your thoughts on the following cost factors?
time_cost = 3
memory_cost = 12
threads = 1The reference library provides a CLI program where these values are
listed. A memory_cost factor of 12 would be 4 MiB.
Looks like there's already some ambiguity in the parameters.
As I understand it, m_cost is the memory size in kilobytes.
Thus, m_cost = 4096 would be 4 MiB.
The source file you referenced [1] has actually LOG_M_COST_DEF,
where m_cost = 1 << LOG_M_COST_DEF.
Testing with argon2_cffi [2] (Python) shows that your parameters
(with m_cost = 4096 = 4 MiB) take 57 ms per hash on my laptop
and 14 ms on my VPS, compared to bcrypt cost 10 taking 88 ms.
Personally, I would be satisfied with even smaller parameters,
maybe something like memory_cost 512, time_cost 2, threads 2.
Disclaimer: I'm not familiar with Argon2, I only looked shortly
at the source files and the Python library [2]. However, care
should be taken to use the correct definition for m_cost.
[1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27
[2] http://argon2-cffi.readthedocs.io/en/stable/parameters.html
--
Lauri Kenttä
On Sat, Aug 6, 2016 at 11:37 AM, Lauri Kenttä lauri.kentta@gmail.com
wrote:
Absolutely. What are your thoughts on the following cost factors?
time_cost = 3
memory_cost = 12
threads = 1The reference library provides a CLI program where these values are
listed. A memory_cost factor of 12 would be 4 MiB.Looks like there's already some ambiguity in the parameters.
As I understand it, m_cost is the memory size in kilobytes.
Thus, m_cost = 4096 would be 4 MiB.
The source file you referenced [1] has actually LOG_M_COST_DEF,
where m_cost = 1 << LOG_M_COST_DEF.Testing with argon2_cffi [2] (Python) shows that your parameters
(with m_cost = 4096 = 4 MiB) take 57 ms per hash on my laptop
and 14 ms on my VPS, compared to bcrypt cost 10 taking 88 ms.Personally, I would be satisfied with even smaller parameters,
maybe something like memory_cost 512, time_cost 2, threads 2.Disclaimer: I'm not familiar with Argon2, I only looked shortly
at the source files and the Python library [2]. However, care
should be taken to use the correct definition for m_cost.[1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L27
[2] http://argon2-cffi.readthedocs.io/en/stable/parameters.html
--
Lauri Kenttä
Hi Laura,
The confusion is on my part, I apologize. Both this implementation, and the
Argon2 reference library use a bitwise shift on the memory cost factor.
When I say "12", I'm really meaning "1<<12", which is 4096, or 4 Mib.
[1][2]. The RFC itself actually states the bitwise shift in the examples,
and for the cost factors represents it in Mib.
We can drop the memory cost down lower if people would prefer that. My only
concern with setting the default thread count to 2 is that it may cause
problems for individuals on single core machines.
The PHP implementation performs as follows from the CLI with the following
cost factors on one of my VPS'. The time cost for each of the Argon2
implementations in this case is 3, with a thread count of 1. [3]
2 ms : argon2i, 256 KiB
2 ms : argon2i, 512 KiB
3 ms : argon2i, 1024 KiB
17 ms : argon2i, 4096 KiB
53 ms : argon2i, 16384 KiB
203 ms : argon2i, 65536 KiB
Setting the memory cost to 4 MiB, or even 1 MiB are pretty fast in the PHP
implementation. I think the following costs would be acceptable to avoid
concerns over memory exhaustion. These appear to be the defaults outlined
in the reference library's CLItool.
memory_cost = 4 MiB, 1<<12
time_cost = 3
threads = 1
I think there's a bunch of ways we can tweak this. As there's no "bad"
values for any of these cost factors per the spec, it may just be easy to
set the costs even lower end user decide if they need to be increased (or
increase them in core at a later time).
memory_cost = 1 MiB 1<<10
time_cost = 2
threads = 1
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?
Typically a run time of of under 50 ms is the target goal. Argon2 can be
tweaked to use a specific amount of memory, time, or CPU cores. Trying to
find good default cost factors is problematic since all 3 of those factors
are variable on any given machine.
Charles R. Portwood II
[1] https://github.com/P-H-C/phc-winner-argon2/blob/master/src/run.c#L160
[2] https://github.com/php/php-src/pull/1997/files#diff-c902
6333c79da7abe3b1285ef7c0c312R36
[3] https://gist.github.com/charlesportwoodii/3e113a53d243b5a722babfd421a93d
c3
[4] https://gist.github.com/charlesportwoodii/ceaa87c9a9adb069b9f2eaddf56ab8
71
On 8/6/16, 1:55 PM, "Charles R. Portwood II"
<charlesportwoodii@ethreal.net on behalf of charlesportwoodii@erianna.com>
wrote:
Typically a run time of of under 50 ms is the target goal. Argon2 can be
tweaked to use a specific amount of memory, time, or CPU cores. Trying to
find good default cost factors is problematic since all 3 of those
factors are variable on any given machine.
(Yes ... the very reason I wanted ... never mind.)
Can anyone think of a way to organize or even automate collection of
timing information together with the relevant specs of the machine the
test was run on? I'm not sure if the qa-reports@lists.php.net process
still operates. Maybe some other idea?
Tom
On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II <
charlesportwoodii@erianna.com> wrote:
I think there's a bunch of ways we can tweak this. As there's no "bad"
values for any of these cost factors per the spec, it may just be easy to
set the costs even lower end user decide if they need to be increased (or
increase them in core at a later time).
Hi everyone,
I've spent the last week and a half playing around with various cost
factors on different virtual machines and hardware (including compiling
this down for armv6 and testing on a Pi Zero), and looking over the spec a
bit more and would like to update the proposal to use the following cost
factors:
memory_cost = 1 MiB
time_cost = 2
threads = 2
There are no "bad" cost factors for Argon2, but obviously more work is
better than less. These cost factors provide sufficient work effort without
exhausting system resources. Argon2 is pretty fast with these cost factors
even on a Pi Zero, which is the most resource constrained system I could
get my hands on. In all my testing I wasn't ever able to get memory
exhaustion to occur just from running argon2 hashing.
I'd like to gather some last feedback and make sure there aren't any
serious objections to these cost factors (or anything else for that matter)
before putting this up for a vote. Please let me know your thoughts.
Thanks,
Charles R. Portwood II
On 8/17/16, 3:48 PM, "Charles R. Portwood II"
<charlesportwoodii@ethreal.net on behalf of charlesportwoodii@erianna.com>
wrote:
Hi everyone,
I've spent the last week and a half playing around with various cost
factors on different virtual machines and hardware (including compiling
this down for armv6 and testing on a Pi Zero), and looking over the spec
a bit more and would like to update the proposal to use the following
cost factors:memory_cost = 1 MiB
time_cost = 2
threads = 2There are no "bad" cost factors for Argon2, but obviously more work is
better than less. These cost factors provide sufficient work effort
without exhausting system resources. Argon2 is pretty fast with these
cost factors even on a Pi Zero, which is the most resource constrained
system I could get my hands on. In all my testing I wasn't ever able to
get memory exhaustion to occur just from running argon2 hashing.I'd like to gather some last feedback and make sure there aren't any
serious objections to these cost factors (or anything else for that
matter) before putting this up for a vote. Please let me know your
thoughts.
Hi Charles,
I trust your judgement in drawing conclusions from these experiments.
Thank you for the work you've put in.
Tom
On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II
charlesportwoodii@erianna.com wrote:memory_cost = 1 MiB
time_cost = 2
threads = 2I'd like to gather some last feedback and make sure there aren't any
serious objections to these cost factors (or anything else for that
matter) before putting this up for a vote. Please let me know your
thoughts.
The whole RFC looks good to me now.
Thanks for your work on this!
--
Lauri Kenttä
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
2016-08-05 18:36 GMT+02:00 Charles R. Portwood II <
charlesportwoodii@erianna.com>:
I think this is the most important part to consider. If you make $options
required for this algo, then making this algo thePASSWORD_DEFAULTwould
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 settingPASSWORD_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.Hi Charles,
I'd prefer
memory_costandtime_costoverm_costandt_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
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
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 toPASSWORD_DEFAULTin 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
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 toPASSWORD_DEFAULTin 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
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