3 ms·
What benefits would you get though? You are still exposing the password_hash to the server and any compromise there (software or hardware, as described in your
by pests 5y ago
What benefits would you get though?
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.
- staticassertion 5y agoIf 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.
- wswope 5y agoIf 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?
- staticassertion 5y agoYou are correct. I (and I think most people?) consider that to be the most common attacker scenario.
- wswope 5y agoGotcha - 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.