Christian,
> Hi Anthony,
> I tried sending this to intern...@php.net but it seems it didn't get
through...
Replying on list.
>> know you didn't like PASSWORD_MOST_SECURE. So what about keeping
>> PASSWORD_DEFAULT as a moving target, documented, and just making the
>> second parameter (algo) to password_hash required? That way users
>
> To be honest I'm not sure of the benefit of making the second parameter
mandatory.
The benefit is that it forces the user to make the choice between a moving
target (the default which will be updated over time) and a specific
algorithm. That way if they need to integrate with other non-PHP
applications, they can stick to a single algorithm that they know both
support.
> Why would I care what the current implementation is? Let's see:
> Previously stored passwords contain an algorithm marker so
password_verify() works.
> New passwords will use the new algorithm when storing passwords but the
actual hash is an opaque value so I should not extract any meaning of it.
> What's the gain of requiring users to be aware of possible algorithm
changes? Before answering please read my two comments below, perhaps they
already cover it.
There are a few other reasons. You cover one of them in the next function
(length requirements). But another is simply to force the user to
acknowledge that the algorithm is designed to change over time (rather than
assuming the default communicates that)...
> There are two things I'd be missing from the perspective of a user of
this function:
> 1) The maximum length of the hash is nowhere specified so if I want to
store it in a DB I don't know how large the field needs to be. That's more
of a documentation issue, I don't think this needs another constant as it
has an impact mainly on the DB schema, not PHP code. This recommended
length should be large enough for future hash algorithms.
Sure, a documentation bit would suffice. I'll put it on my list to update
the RFC with...
> 2) I'd like to be able to check wether a stored password uses an outdated
algorithm and update the hash in that case. For that I'd need either a
function to extract the salt from a hash to pass it to password_hash() and
compare the result with the old hash. Or preferably a separate function
password_hash_outdated($hash) => bool or something similar. Or maybe
someone can come up with yet a better solution for this.
Well... I don't know about that. Outdated is a very odd concept here.
Perhaps, a password_hash_get_algo($hash) call would suffice. That way, you
could do if (PASSWORD_BCRYPT == password_get_hash_algo($hash)) { //upgrade
hash }. Or even if (PASSWORD_DEFAULT != password_get_hash_algo($hash))...
Speaking of which, since algorithms can be introduced over time, should a
new function password_algos() be added to return an indexed array of
supported algorithms?
Thanks!
Anthony
