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. 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.
