On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer wrote:
> On 26-7-2024 0:00, Nick Lockheart wrote:
>
> >
> > That's a good point. What if there were crypto functions that
> > worked
> > like password_hash() in that they had one generic function name,
> > but
> > magically used the new/better "best practice" algorithms as time
> > went
> > by without the need to update any calling code?
> >
> > Maybe there should be three generic-named functions:
> >
> > fast_hash() // not secure, makes UIDs quickly
> > secure_hash() // uses best practice one-way hash algo
> > secure_crypt() // uses best practice reversible encryption.
>
> While I like the idea, this sounds like a huge nightmare in the
> waiting when data is stored somewhere and later compared.
>
> Example:
> * Let's say these functions get introduced in PHP 8.5.
> * secure_hash() is used in an application running on PHP 8.5 to
> secure some data before storing it in a database. This data is used
> in comparisons - stored vs user provided.
> * Now in PHP 9.1, the hash algorithm is changed.
> * The production environment gets updated to PHP 9.1 and suddenly
> the application breaks as the data verification will no longer work
> as the new algo is used on the user provided data, but the database
> stored version of the same data was created with the old algo....
>
Doesn't password_hash() handle this automatically? The result of the
password_hash() function includes the hash and the algorithm used to
hash it. That way password_verify() magically works with the string
that came from password_hash().