On Sat, Aug 6, 2016 at 6:09 AM, Niklas Keller <m...@kelunik.com> wrote:
> 2016-08-05 22:51 GMT+02:00 Lauri Kenttä <lauri.ken...@gmail.com>:
>
>> On 2016-08-05 21:20, Charles R. Portwood II wrote:
>>
>>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster <f...@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
