On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas <derokor...@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 <m...@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. Thanks, *Charles R. Portwood II*
