On: Using HTTP Basic Auth in 2022

[_ofdw]

>Yes - it does - but I am having a hard time thinking that this actually matters in the real world.

In the 90s and early aughts it was fashionable for php sites to store passwords hashed, usually some combination of a salt with md5 and later the SHA variants.

For a brief few years there were entire communities on IRC and elsewhere dedicated to making rainbow tables for cracking stolen password hashes.

Often the salt would be common across all passwords, so if you got a database dump it was a gold mine for credentials.

[staticassertion → _ofdw]

A trivial fix here is to:

a) Add a static value to the salt ie: your company's name

b) Add the user's email address to the salt

The "right" way would be a zero knowledge proof.

[_ofdw → staticassertion]

Yeah well PHPnuke wasn't exactly written by secure coding experts.

[gjsman-1000 → _ofdw]

Right - but that's been resolved, PHP and others now store the unique salt used with the password together, so every password has its own salt.

That didn't need client-side hashing to fix it.

[garbagecoder → gjsman-1000]

Gee, it’s almost like on the internet there are computers between you and the destination.

[Too → _ofdw]

bcrypt solves that in two ways. It uses per password unique salts and it has a tunable cost-parameter to deliberately slow down the computation, making it slow and infeasible to build a rainbow table.