Re:Using HTTP Basic Auth in 2022
by staticassertion on Saturday January 01, 2022 @05:09PM
(#29763367)
If the attacker only has access to the hash that hash is only usable for your website. If the user uses the same password for another site an attacker can not log into that other site using the hash.
That's really the main benefit of this approach - it reduces the impact of password reuse.
If I’m understanding your argument correctly (I may not be) - implementing PAKE would only be helpful in a scenario where an attacker gets access to hashed passwords, but isn’t able to modify front-end code to directly intercept unhashed passwords, right?
Re:Using HTTP Basic Auth in 2022
by staticassertion on Saturday January 01, 2022 @05:36PM
(#29763583)
You are correct. I (and I think most people?) consider that to be the most common attacker scenario.
Gotcha - and I can definitely see the utility with a large userbase.
From a corporate perspective, with a segmented + well-firewalled architecture, and a lot of surface area for injection vulns, I totally agree with you. The article was priming me to think of a flat, single-box solodev environment, where if someone breaks in, they own everything - which is why I think the original post above us mentioning PAKE is getting a lot of questioning.
You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your link) would still let an attacker grab password_hash, craft a custom client, and send it as if the original client had hashed the plaintext_password to begin with.
The attacker doesn't need to know plaintext_password, just the string you use to authenticate with in order to replay it. The password_hash becomes the new password.
Then due to the salt being on the client, it still opens the password up to rainbow table attacks etc.