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().
