On Fri, Jul 26, 2024, at 08:44, Rowan Tommins [IMSoP] wrote:
>
>
> On 25 July 2024 23:54:53 BST, Nick Lockheart <[email protected]> wrote:
> >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().
>
> For password hashing, you are always retrieving the hash for a specific user, and then making a
> yes/no decision about it. Indeed, it's an explicit aim that an attacker can't take a
> password and quickly scan a captured database for matching hashes.
You’d be surprised how many projects get this wrong and claim it isn't a security issue. If
you can get the hashes, you likely have the ability to run arbitrary sql commands and since
password_hash stores the salt right in the hash, you just need to crack one easy to guess password
-- or just run password_hash on your machine ... then copy it to whatever user you want to login as.
Very few php projects salt the passwords with something application/user specific (see:
symfony's legacy password implementation which does, and new one which does not; and yes I
reported it, and yes, it "isn't a security issue") to prevent this from happening.
There are other bad defaults, such as pdo_mysql allowing more than one sql statement (but all other
drivers not -- and mysqli is also not)... making it even easier to open yourself up to getting
hacked if you use pdo with mysql; allowing a single injection to be used to insert/update or even
drop tables.
Security is something hard to get right, for any language and framework. PHP isn't an exception
here; you have to pay attention to what you are doing and think like an attacker, every step of the
way.
>
> For other uses of hashes, though, the opposite is true: you want to search for matching hashes.
> For instance, when you store a file in git, it calculates the SHA1 hash of its content to use as a
> lookup key. If that key already exists in the local database, it assumes the content is the same.
>
> That also demonstrates another difference: hashes are often shared between applications, where
> they need to be using an agreed algorithm. If a package manager requires SHA1 hashes of each file,
> you can't just substitute SHA256 hashes without some other agreed changes.
>
> Tempting though a "secure_hash" function is, I don't think it's practical
> for a lot of the places hashing is used.
I think we can borrow from a recent RFC to return more than one thing:
secure_hash($data, $algorithm = null): [$algorithm, $hash, $updated_algorithm, $updated_hash];
if you pass in an algorithm, it has to have been considered "secure" within the last two
major versions*, it also returns an optional "updated" part, where it can be used to
update the hash in your database, if needed.
— Rob