6 ms·

I probably would never try to implement this on my own website. My login pages don't use JS, so unless the browser did the work for me, it's complexity that I'm

I probably would never try to implement this on my own website. My login pages don't use JS, so unless the browser did the work for me, it's complexity that I'm never going to understand running on the most crucial page on my site. Moreover, though, users run so much shit in their browsers. More than half of the logged errors on my site are from user scripts and browser extension content scripts doing lord knows what. They can all just slurp the value out of the DOM, no questions asked. Never mind my CSP, HTTPS, and all of the effort I go to making my server environment secure and safe. The weakest link is not the password getting sent to my servers (over HTTPS), it's the utter free-for-all happening on the page in the first place.

tptacek 5y ago
It's really hard to come up with a sane reason why you would ever implement a PAKE with a browser HTTPS application. Probably the best-known use of any PAKE is in Magic Wormhole, where the PAKE passphrase (auto-generated) is a fundamental part of the trust model, and the application itself never touches a browser. It's a problem with PAKEs that they're kind of neat to think about and play with, so people look for things to stick them onto. They're usually not the answer, which is why you don't see them used all that often, and why they're used almost exclusively in custom protocol settings. (It doesn't help PAKE adoption that most custom protocols are better served by standard authenticated key exchanges based on real cryptographic secrets, rather than passphrases).
- nly 5y ago
  Indeed. It's hard to come up with use cases where a chosen, long-term low entropy secret is more suitable than alternatives like: 1) Factory paired devices 2) Pairing via ephemeral key pairs with out-of-band verification of a low entropy hash/fingerprint to prevent active MITM. 3) Straight up TOFU (trust on first use) pairing (and just praying MITM doesn't happen on first use). The only case comes to mind is one where one device, although still physically trusted, has no persistent memory at all (and so can't store any keys).
- GoblinSlayer 5y ago
  A mentioned use case is twitter logging requests on server side.
  - br1 5y ago
    Exactly, it's to protect your user from you.
- amluto 5y ago
  If we could go back in time and teach users that passwords are only to be entered into browser chrome, and if that used PAKE, we would be in pretty good shape.
  - nly 5y ago
    HTTP Basic Authentication was a thing in the 90s. Couple that with TLS+PFS and you already have all the benefits of PAKE, plus the more useful benefit of having a third party verify the identify of the web server the first time you visit. The major reason HTTP Auth failed, despite the primitive crypto, is the bad client side UX.
    - jimktrains2 5y ago
      Not _all_ the benefits. PAKE doesn't share the password with thr server. I would argue the reason http auth failed is that there is no means of logging out, part of that is ui, part of that is protocol.
      - nly 5y ago
        > PAKE doesn't share the password with thr server. The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline. I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.
        jimktrains2 5y ago
        Of course if you have the server config and database you could impersonate it. However, phishing would be nearly pointless as most phished sites aren't/hadn't been compromised. (Well, pointless in the universe where entering a password into form elements and not the browser chrome isn't common and taught as a faux pas to users.) Also, as it is you can brute force hashes offline as well. Yes, the original specification has become weak over time, but so have 3des and md5. SRP never was heavily used and as such new versions arent common; it's not inherently a problem with the concept of password-based mutual authentication.
- cvwright 5y ago
  Here's one example where a PAKE would be very helpful. In Matrix E2EE chat, every user winds up with a ton of different E2EE sessions and thus a ton of different keys that they need to store. (This part of the protocol is unnecessarily complicated IMO, but it's too late to change it now.) The key to making multi-device support work in practice has been to store an encrypted archive of all the keys for all your sessions, in encrypted form on the server. Where do you get the key for this encryption? It seems the only workable option is to derive it from a passphrase, since the user might choose to log in from a new device (or a new browser) at any moment. So the secret has to live only in the user's head. But now each user has to remember two passwords: (1) their login password and (2) their encrypted key backup password. Do we really believe that they will pick two totally different, independent passwords??? And if they don't, then in what way are the E2EE keys protected from the server? So it would be great if we could prevent the server ever learning the login password. For that reason, a few of us random volunteers have been looking at adding SRP or SCRAM or something to Matrix.
  - tptacek 5y ago
    I don't understand why you would ever protect an encrypted archive of keys stored serverside with a passphrase authenticated from a password hash stored on the server (which is effectively how a PAKE works). It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. (SRP is pretty much dead now, for what it's worth).
    - cvwright 5y ago
      Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is lazy and uses the same password for both purposes, then the server could very easily derive the key and decrypt the blob that contains all of the E2EE keys. Even if the user picks slightly different passwords, e.g. "password1" vs "password2", the server has a huge advantage over your standard brute force attacker. > (SRP is pretty much dead now, for what it's worth). :shrug: Was it ever really alive?
- hirsin 5y ago
  Password authentication to something running on local network (and therefore can't get a useful TLS cert) is about it, in my experience. Use the PAKE in place of TOFU to trust a self-signed TLS cert in the browser and get rid of cert warnings, since in my understanding PAKE also helps authenticate the server, not just the user.
GoblinSlayer 5y ago
There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.
- bastawhiz 5y ago
  Even if it's conceptually simpler, it still suffers from the same issues in my comment
  - GoblinSlayer 5y ago
    If you mean login without javascript, that can't be helped. If you mean password slurped from DOM, you can't possibly make it worse.
    - bastawhiz 5y ago
      Conceptually there's no reason this couldn't be implemented by the browser with a new password element and a protocol built on top of HTTPS.
      - GoblinSlayer 5y ago
        FWIW there's an experimental RFC 7804, but I don't know if any browser implemented it.
- nmadden 5y ago
  Right. SCRAM is only secure if you already have a secure channel - eg if you’ve already done a TLS handshake with certificate auth. A PAKE is secure on its own. However, IMO most people saying they need a PAKE could use SCRAM instead and actually have a chance of understanding what they have deployed.
mabbo 5y ago
The issues is that passwords are red data and you want to minimize the number of places red data exists and can be leaked. Consider the Twitter issue mentioned in the article. Logging inputs is a very common thing and is often important for security auditing later. But if you add it, you need to make sure you're censoring passwords. If you do that wrong, or something around it later changes, you're leaking plaintext passwords to your logs. And that's just one angle. There's also db compromise. DB snapshot/backup compromise. There's a dozen more dangerous attack surfaces we haven't even thought of yet. PAKE means that no matter what you do, you can't leak a plaintext password because you don't know it. That's why it's powerful.
- bastawhiz 5y ago
  PAKE also means one more thing that can break and one more library (actually two libraries, unless you're running Node) that can have serious security issues. Those are tradeoffs, and the purism of never handling red data doesn't necessarily offset its costs. Especially in a small organization. If you're going to spend N hours on security, what's going to give you the biggest bang for your buck? PAKE would hardly crack my top 20, honestly. Are you confident your deps are updated quickly after CVEs are published? Is your server's kernel up to date? Are you sure your security group configuration is correct right now? Do you have lint rules to protect against XSS issues? PAKE makes a really bad issue slightly less bad, but there's thousands of things that you could be doing that meaningfully prevent issues in the first place. If 0.5% of your users get a JavaScript exception from the PAKE library, are you confident that you can fix it? What's the cost of those users not being able to log in (and/or churning)? When it comes to low hanging fruit at most small businesses, handling of plaintext passwords delivered over a secure connection is small potatoes compared to the myriad of other serious security challenges you're likely facing.

tptacek 5y ago

It's really hard to come up with a sane reason why you would ever implement a PAKE with a browser HTTPS application. Probably the best-known use of any PAKE is in Magic Wormhole, where the PAKE passphrase (auto-generated) is a fundamental part of the trust model, and the application itself never touches a browser. It's a problem with PAKEs that they're kind of neat to think about and play with, so people look for things to stick them onto. They're usually not the answer, which is why you don't see them used all that often, and why they're used almost exclusively in custom protocol settings. (It doesn't help PAKE adoption that most custom protocols are better served by standard authenticated key exchanges based on real cryptographic secrets, rather than passphrases).

nly 5y ago
Indeed. It's hard to come up with use cases where a chosen, long-term low entropy secret is more suitable than alternatives like: 1) Factory paired devices 2) Pairing via ephemeral key pairs with out-of-band verification of a low entropy hash/fingerprint to prevent active MITM. 3) Straight up TOFU (trust on first use) pairing (and just praying MITM doesn't happen on first use). The only case comes to mind is one where one device, although still physically trusted, has no persistent memory at all (and so can't store any keys).
GoblinSlayer 5y ago
A mentioned use case is twitter logging requests on server side.
- br1 5y ago
  Exactly, it's to protect your user from you.
amluto 5y ago
If we could go back in time and teach users that passwords are only to be entered into browser chrome, and if that used PAKE, we would be in pretty good shape.
- nly 5y ago
  HTTP Basic Authentication was a thing in the 90s. Couple that with TLS+PFS and you already have all the benefits of PAKE, plus the more useful benefit of having a third party verify the identify of the web server the first time you visit. The major reason HTTP Auth failed, despite the primitive crypto, is the bad client side UX.
  - jimktrains2 5y ago
    Not _all_ the benefits. PAKE doesn't share the password with thr server. I would argue the reason http auth failed is that there is no means of logging out, part of that is ui, part of that is protocol.
    - nly 5y ago
      > PAKE doesn't share the password with thr server. The server has a password derivative stored. An SRP verifier for instance is computed from the password hash, so if the server is compromised the hacker can immediate impersonate the server or the password can be brute-forced offline. I believe OPAQUE is the same, just with stronger (slower) password hash functions in the mix.
      - jimktrains2 5y ago
        Of course if you have the server config and database you could impersonate it. However, phishing would be nearly pointless as most phished sites aren't/hadn't been compromised. (Well, pointless in the universe where entering a password into form elements and not the browser chrome isn't common and taught as a faux pas to users.) Also, as it is you can brute force hashes offline as well. Yes, the original specification has become weak over time, but so have 3des and md5. SRP never was heavily used and as such new versions arent common; it's not inherently a problem with the concept of password-based mutual authentication.
cvwright 5y ago
Here's one example where a PAKE would be very helpful. In Matrix E2EE chat, every user winds up with a ton of different E2EE sessions and thus a ton of different keys that they need to store. (This part of the protocol is unnecessarily complicated IMO, but it's too late to change it now.) The key to making multi-device support work in practice has been to store an encrypted archive of all the keys for all your sessions, in encrypted form on the server. Where do you get the key for this encryption? It seems the only workable option is to derive it from a passphrase, since the user might choose to log in from a new device (or a new browser) at any moment. So the secret has to live only in the user's head. But now each user has to remember two passwords: (1) their login password and (2) their encrypted key backup password. Do we really believe that they will pick two totally different, independent passwords??? And if they don't, then in what way are the E2EE keys protected from the server? So it would be great if we could prevent the server ever learning the login password. For that reason, a few of us random volunteers have been looking at adding SRP or SCRAM or something to Matrix.
- tptacek 5y ago
  I don't understand why you would ever protect an encrypted archive of keys stored serverside with a passphrase authenticated from a password hash stored on the server (which is effectively how a PAKE works). It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. (SRP is pretty much dead now, for what it's worth).
  - cvwright 5y ago
    Yeah, sorry if my description wasn't clear. > It sounds like what you want is a password-based KDF, to derive keys clientside for the encrypted bundle. The encrypted blob containing E2EE keys is encrypted with a symmetric key that's derived from PBKDF2 on a passphrase. The problem is that standard password-based authentication exposes the login password to the server every time the user logs in. So if the user is lazy and uses the same password for both purposes, then the server could very easily derive the key and decrypt the blob that contains all of the E2EE keys. Even if the user picks slightly different passwords, e.g. "password1" vs "password2", the server has a huge advantage over your standard brute force attacker. > (SRP is pretty much dead now, for what it's worth). :shrug: Was it ever really alive?
hirsin 5y ago
Password authentication to something running on local network (and therefore can't get a useful TLS cert) is about it, in my experience. Use the PAKE in place of TOFU to trust a self-signed TLS cert in the browser and get rid of cert warnings, since in my understanding PAKE also helps authenticate the server, not just the user.

GoblinSlayer 5y ago

There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.

bastawhiz 5y ago
Even if it's conceptually simpler, it still suffers from the same issues in my comment
- GoblinSlayer 5y ago
  If you mean login without javascript, that can't be helped. If you mean password slurped from DOM, you can't possibly make it worse.
  - bastawhiz 5y ago
    Conceptually there's no reason this couldn't be implemented by the browser with a new password element and a protocol built on top of HTTPS.
    - GoblinSlayer 5y ago
      FWIW there's an experimental RFC 7804, but I don't know if any browser implemented it.
nmadden 5y ago
Right. SCRAM is only secure if you already have a secure channel - eg if you’ve already done a TLS handshake with certificate auth. A PAKE is secure on its own. However, IMO most people saying they need a PAKE could use SCRAM instead and actually have a chance of understanding what they have deployed.

mabbo 5y ago

The issues is that passwords are red data and you want to minimize the number of places red data exists and can be leaked. Consider the Twitter issue mentioned in the article. Logging inputs is a very common thing and is often important for security auditing later. But if you add it, you need to make sure you're censoring passwords. If you do that wrong, or something around it later changes, you're leaking plaintext passwords to your logs. And that's just one angle. There's also db compromise. DB snapshot/backup compromise. There's a dozen more dangerous attack surfaces we haven't even thought of yet. PAKE means that no matter what you do, you can't leak a plaintext password because you don't know it. That's why it's powerful.

bastawhiz 5y ago
PAKE also means one more thing that can break and one more library (actually two libraries, unless you're running Node) that can have serious security issues. Those are tradeoffs, and the purism of never handling red data doesn't necessarily offset its costs. Especially in a small organization. If you're going to spend N hours on security, what's going to give you the biggest bang for your buck? PAKE would hardly crack my top 20, honestly. Are you confident your deps are updated quickly after CVEs are published? Is your server's kernel up to date? Are you sure your security group configuration is correct right now? Do you have lint rules to protect against XSS issues? PAKE makes a really bad issue slightly less bad, but there's thousands of things that you could be doing that meaningfully prevent issues in the first place. If 0.5% of your users get a JavaScript exception from the PAKE library, are you confident that you can fix it? What's the cost of those users not being able to log in (and/or churning)? When it comes to low hanging fruit at most small businesses, handling of plaintext passwords delivered over a secure connection is small potatoes compared to the myriad of other serious security challenges you're likely facing.