On: Using HTTP Basic Auth in 2022

[huntertwo]

If the hash is used to authenticate, how is leaking the hash less bad than leaking the password? If I have the hash I can already impersonate you.

[Too → huntertwo]

The hash is not constant.

With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key.

Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.

[staticassertion → Too]

Yeah, once you get to the ZKP approach, which is what you're describing, the benefits are more significant.

[u801e → Too]

> With public key crypto you can implement a challenge response.

Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.

[staticassertion → huntertwo]

There are like a dozen other posts where I answer this question so I'd recommend just going to my comment history.

[PuercoPop → huntertwo]

Because many inputs map to that hash (the hashing function is surjective instead of bijective). People re-use passwords all the time. If the hash leaks it will only affect the particular service.

[gsich → huntertwo]

Because pass the hash only works for the current server. People reuse passwords, so without brute-forcing you are out of luck.