On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II < charlesportwoo...@erianna.com> wrote:
> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster <f...@thefsb.org> wrote: > > > On 8/5/16 8:47 AM, Charles R. Portwood II wrote: > > Finally, I wonder if it wouldn't be better if, for the time being, we > > do not provide default costs constants. Argon2 is new (as crypto algos > > go) and very early in a gradual introduction in deployments. And it is > > hard to use because of the three cost factors. Correctly tuning those > > for different machines is not yet a commonly-understood skill. (You > > even can find conflicting advice on how to tune Bcrypt's time factor.) > > > > > If, on the other hand, we omit the constants and require the $options > > argument then it discourages inexpert users. At the same time it > > encourages experimentation and understanding of the costs, among those > > who take an interest, which I think is just what we want. > > > The rationale for providing defaults is to ensure the password_* functions > remain easy 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 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.
