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

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.