6 ms·

- If you share your password across sites that used a hypothetical browser-implemented PAKE, site A cannot login to your account on site-B - If a site is attac

- If you share your password across sites that used a hypothetical browser-implemented PAKE, site A cannot login to your account on site-B - If a site is attacked, there is no risk that password material was extracted from application memory — site operator can dump session tokens and safely re-auth users.

gjsman-1000 5y ago
This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.
- staticassertion 5y ago
  PAKE isn't theoretical at all and the post you're responding to didn't say client side hashing it said zero knowledge proofs.
  - gjsman-1000 5y ago
    PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now. Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
    - staticassertion 5y ago
      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.
    - joelbondurant 5y ago
- indymike 5y ago
  The first implementation was Bellovin and Merritt's Encrypted Key Exchange in 1992. In 2000 a provably secure implementation was released. PAKE has been around for quite some time and is proven, and is in wide use in the field. Here's a decent article on the subject: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
  - gjsman-1000 5y ago
    I don't dispute the technology exists - I dispute that this technology can be deployed on a web app to general users effectively. I don't believe that is currently possible in production effectively in a way that neutralizes my arguments that an attacker could just change the JavaScript to record passwords somewhere.
    - madacol 5y ago
      That's why the browser's built-in login Form could be so useful, it would have its own security context, so I, as a user can be sure that no Javascript could read that I would happily sign up and reuse a password for a website that I didn't trust if it were as secure as described (PAKE + browser built-in login)
    - indymike 5y ago
      I'm really not sure what you are disputing here. PAKEs are for preventing man in the middle attacks, not for securing a local program or preventing malicious code from running in the browser. No one is advocating, use a PAKE and all your problems are gone - it's about addressing key exchange over the wire and eliminating an entire class of attack. Password managers are a tough subject - they are like coffee . Yes, there may be small amounts of toxic stuff in it, but that is offset by a factor of 10,000 by the number of people who do not get in a wreck on the way to work, thanks to being awake and aware form 70mg of caffeine.
- scoopertrooper 5y ago
  Not theoretical, you can do it today. https://www.npmjs.com/package/libopaque https://www.npmjs.com/package/libopaque
- somebodythere 5y ago
  Metamask basically works this way and is used on thousands of apps.

gjsman-1000 5y ago

This sounds like an interesting system, but I think you are arguing for a system that as-of-now is only theoretical and is very different against the current crop of JavaScript-powered client-side-hashing methods which I am arguing against.

staticassertion 5y ago
PAKE isn't theoretical at all and the post you're responding to didn't say client side hashing it said zero knowledge proofs.
- gjsman-1000 5y ago
  PAKE is theoretical from a web-development perspective because there is no secure way for me to implement PAKE in my web app for a user to log in with in 2022. It doesn't exist - you tell me how to implement PAKE login right now. Zero Knowledge Proofs would be awesome (something like WebAuthn/FIDO right now?) but I am arguing more in general against client-side hashing methods that are currently usable, mainly JavaScript-based ones.
  - staticassertion 5y ago
    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.
  - joelbondurant 5y ago
indymike 5y ago
The first implementation was Bellovin and Merritt's Encrypted Key Exchange in 1992. In 2000 a provably secure implementation was released. PAKE has been around for quite some time and is proven, and is in wide use in the field. Here's a decent article on the subject: https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
- gjsman-1000 5y ago
  I don't dispute the technology exists - I dispute that this technology can be deployed on a web app to general users effectively. I don't believe that is currently possible in production effectively in a way that neutralizes my arguments that an attacker could just change the JavaScript to record passwords somewhere.
  - madacol 5y ago
    That's why the browser's built-in login Form could be so useful, it would have its own security context, so I, as a user can be sure that no Javascript could read that I would happily sign up and reuse a password for a website that I didn't trust if it were as secure as described (PAKE + browser built-in login)
  - indymike 5y ago
    I'm really not sure what you are disputing here. PAKEs are for preventing man in the middle attacks, not for securing a local program or preventing malicious code from running in the browser. No one is advocating, use a PAKE and all your problems are gone - it's about addressing key exchange over the wire and eliminating an entire class of attack. Password managers are a tough subject - they are like coffee . Yes, there may be small amounts of toxic stuff in it, but that is offset by a factor of 10,000 by the number of people who do not get in a wreck on the way to work, thanks to being awake and aware form 70mg of caffeine.
scoopertrooper 5y ago
Not theoretical, you can do it today. https://www.npmjs.com/package/libopaque https://www.npmjs.com/package/libopaque
somebodythere 5y ago
Metamask basically works this way and is used on thousands of apps.