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

2016-08-05 18:36 GMT+02:00 Charles R. Portwood II < charlesportwoodii@erianna.com>: > On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas <derokorian@gmail.com> wrote: > > > > > > 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. > > > > > > > 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. > > > 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. > > On Fri, Aug 5, 2016 at 11:29 AM, Niklas Keller <me@kelunik.com> wrote: > > > > 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 > > > > '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