4 ms·

Not sure what you mean. 1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ? > I am arguing more in

Not sure what you mean. 1. There is, of course, a way to implement it in your web app. I don't know what you mean by "no secure way" ? > I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones. Even a trivially implemented client side hashing approach protects against a number of attacks.

gjsman-1000 5y ago
I meant, let's say I picked a framework. Django, Laravel, Express, similar. How would I implement PAKE login for my users? How would I get every user to log in with PAKE? How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server? It doesn't exist, AFAIK, on a user-facing front at this time in a secure way that a hacker couldn't just change the logic for.
- cassonmars 5y ago
  PAKE isn’t about preventing compromise at the serving of the front end. That’s still the responsibility of the server maintainer. PAKE is about reducing damage potential. The responsibility of keeping your servers secure applies regardless of use of PAKE. PAKE just makes it possible that if your database is leaked in some smash-and-grab someone can’t just run a rainbow table against it to suss out passwords against emails.
- staticassertion 5y ago
  Implementing opaque isn't overly hard. You can find pseudocode, implementations, state machine diagrams, etc, online. Here's a good post that links to implemented code: https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/ I know nothing of framework support, I don't use frameworks. I'm likely going to contribute some open source code in the near future from my company to simplify things though. But you could also just have your client do: salt = sha256("your company name goes here" + username) password_hash = pbkdf2(plaintext_password, salt) and get some nice benefits. > How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server? Depends on the server and the level of control. But it'll help in a number of cases. You're assuming the attacker has full control over the web-page's contents (among other things - even if an attacker had the web page's contents CORS means they couldn't send http only cookies to an attacker controlled server), which is a very specific, powerful position to be in.
  - 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 ago
      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.
      - wswope 5y ago
        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?
        staticassertion 5y ago
        You are correct. I (and I think most people?) consider that to be the most common attacker scenario.
        wswope 5y ago
        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.

gjsman-1000 5y ago

I meant, let's say I picked a framework. Django, Laravel, Express, similar. How would I implement PAKE login for my users? How would I get every user to log in with PAKE? How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server? It doesn't exist, AFAIK, on a user-facing front at this time in a secure way that a hacker couldn't just change the logic for.

cassonmars 5y ago
PAKE isn’t about preventing compromise at the serving of the front end. That’s still the responsibility of the server maintainer. PAKE is about reducing damage potential. The responsibility of keeping your servers secure applies regardless of use of PAKE. PAKE just makes it possible that if your database is leaked in some smash-and-grab someone can’t just run a rainbow table against it to suss out passwords against emails.
staticassertion 5y ago
Implementing opaque isn't overly hard. You can find pseudocode, implementations, state machine diagrams, etc, online. Here's a good post that links to implemented code: https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/ I know nothing of framework support, I don't use frameworks. I'm likely going to contribute some open source code in the near future from my company to simplify things though. But you could also just have your client do: salt = sha256("your company name goes here" + username) password_hash = pbkdf2(plaintext_password, salt) and get some nice benefits. > How would I ensure that my code for PAKE could not be overwritten if a hacker took over part of my server? Depends on the server and the level of control. But it'll help in a number of cases. You're assuming the attacker has full control over the web-page's contents (among other things - even if an attacker had the web page's contents CORS means they couldn't send http only cookies to an attacker controlled server), which is a very specific, powerful position to be in.
- 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 ago
    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.
    - wswope 5y ago
      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?
      - staticassertion 5y ago
        You are correct. I (and I think most people?) consider that to be the most common attacker scenario.
        wswope 5y ago
        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.