Re: Re: [RFC][DISCUSSION] Argon2 Password Hash

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