6 ms·

Unfortunately this won't help while we continue to trust JS sent to us by the server. Their threat model is "server is compromised by an attacker, who then vac

Unfortunately this won't help while we continue to trust JS sent to us by the server. Their threat model is "server is compromised by an attacker, who then vacuums up all the cleartext passwords". Assuming that under normal operations there's some fancy UI that takes the password and handles the PAKE stuff (which it will have to be, until browsers support it), there's nothing stopping that attacker from simply adding malicious code that fire off your cleartext password. If you want user authentication security, use client side TLS certs. 1) the UI is built into all major browsers, and can't be faked, and 2) the server doesn't require the CA's private key, only the server generating new certs needs it. In the above threat model, the worst that can happen if an attacker compromises the server is he can MITM the traffic at the time... but the attacker will never capture user credentials that can be used in the future, or be used to decrypt past communications.

akerl_ 8y ago
The problem that exists with TLS certs, and not with PAKE, is usability. Client certs suffer from questions like "as a user, how do I handle multiple devices? Logging in from my phone? Logging in from the biz center at some hotel / my friend's phone / etc? The UX for client certs in browsers makes it a pain to use even as a tech-savvy person; if we want it to actually become popular as a web auth method, it has to start with better UX.
- amelius 8y ago
  Yes, see "PGP" for an example where good crypto tech fails when the UX is not on par.
- parliament32 8y ago
  To be fair the UX for client side certs is pretty idiotproof once you have the cert installed. You get a "X site is requesting an identity certificate" box. Installing certs is pretty painless too -- you navigate to a certain page and get a "this site is attempting to install a security identification certificate in your browser" box. Securely getting to that page is a different matter. As for logging in on untrusted devices (biz center, friend's PC, etc)... you shouldn't be doing that under any circumstances in a high security situation.
  - dogma1138 8y ago
    The problem with certificates is that A) it requires the user to install them on every device B) they are required to be installed on every device C) they are a bitch to manage and distribute and D) protection around certificates is fairly weak and any client compromise will lead to the exposure of all credentials. You also end up delegating the authentication to your transport layer which is never that good of an idea.
    - elblanko 8y ago
      I think most linux distro's protection of certificate private keys is pretty weak (just storing a .pem file somewhere) and I can't say anything about OSX but on Windows you can prevent the private key from being disclosed even if the user wants to export it and enforce entering a password or PIN each time the certificate is used. Getting access to the physical hardware is about the only way to bypass the CryptoAPI, which is pretty far from 'any' client compromise.
      - tialaramex 8y ago
        You can't actually "prevent the private key from being disclosed even if the user wants to export it" out of box on Windows [if you have an HSM this may be an option although it may also make the keys unsuitable for some purposes]. You can make it _annoying_ which is a stock in trade for Microsoft designs, but attackers don't care about it being annoying. The reason is that the CryptoAPI hands over the keys to an application for it to use (it does not function only as a proxy like say ssh-agent), and so application can export the keys. People even make ready-to-use apps to do this, because, as described above, the CryptoAPI behaviour is annoying. You can require a password, but that's true for text files on a Linux system too. So why don't most people use a secret password to protect a file with a secret key inside it? Because it's yet more pointless busy work, again a stock in trade of Microsoft environments. Also, because this is so very annoying you don't need physical access but only console access, which you can of course get remotely, as otherwise administrators of the mountains of Windows servers set up this way couldn't type in all the passwords needed over RDP every day. (If you're lucky they are using an encrypted RDP session to do this...)
- derefr 8y ago
  > Client certs suffer from questions like "as a user, how do I handle multiple devices? Logging in from my phone? Logging in from the biz center at some hotel / my friend's phone / etc? I see this as a perfect case for "logging into your browser" (Chrome Sync/Firefox Sync/iCloud Safari Keychain sync/etc.) Why not have any issued client certs be global to your "browser account" rather than local to your device? The cert bundles can also be transferred and stored using end-to-end encryption (like iMessage keybags.) Sure, now you can't tell which of a person's devices they're on from just the cert you're seeing. That's what cookies or localStorage would be for, since they explicitly don't sync between devices. Client cert for AAA + session cookie for holding the server-side connection ID.
arkadiyt 8y ago
It still feels marginally better because it requires making a change that is visible to users, vs the normal case where a server can surreptitiously collect passwords. It also works nicely for the mobile app login case.
hinkley 8y ago
You want your browser to support PAKE, not for the website to send javascript. Lack of native browser support seems to be what held up SRP. Hopefully OPAQUE can make it farther.
- tptacek 8y ago
  It seems unlikely. The differences between OPAQUE and SRP aren't what kept SRP from being adopted. The fact that SRP doesn't really solve a problem that most organizations care about for their web applications is a bigger issue. Remember, virtually all mainstream applications accept logins over TLS (exclusively) at this point, so being able to authenticate and encrypt a channel with a passphrase isn't all that valuable. As a security engineer working for a startup, there aren't a lot of new features I'd be able to build after having adopted SRP, and essentially none of my real current challenges (credential stuffing, phishing) would get any easier. That's not to say OPAQUE isn't useful; it's just not that useful in SAAS-type application settings.
  - gok 8y ago
    What about the "oops we accidentally logged passwords in plain text" issue mentioned in the article?
    - tptacek 8y ago
      I don't believe that's a security concern that motivates entire new protocols; further, I think it's one of those security issues that is talked about more than it is actually felt. So far as I know, none of the HIBP datasets have come from logs? I'd be interested in corrections. The "real" issue PAKEs address is long-term compromise, where an attacker can observe passwords out of memory. For that matter: for attackers to get log files in the first place, 9 times out of 10 they had to get RCE somewhere in prod, and that is already game over. And, there's a lot of things you'd do first do address game-over than replacing your TLS login POST with a PAKE handshake.
      - gok 8y ago
TimTheTinker 8y ago
You're assuming the client-side PAKE implementation must be provided by JS sent from the server. Why not implement a client-side PAKE API in the browser? It could be designed to disallow any server-sent code from accessing client credentials in plaintext, while still allowing styling and layout of credentials fields (this might be impossible, though). Or alternatively, let the browser handle the login/credentials UI, and build in a seamless password manager integration.
e12e 8y ago
Wasn't there talk about removing support for client side certs, either in the rfcs and/or major browsers? (citing ux problems) I can't seem to find any relevant links/bugs now though - maybe the decision was reversed? Or I'm simply wrong?

akerl_ 8y ago

The problem that exists with TLS certs, and not with PAKE, is usability. Client certs suffer from questions like "as a user, how do I handle multiple devices? Logging in from my phone? Logging in from the biz center at some hotel / my friend's phone / etc? The UX for client certs in browsers makes it a pain to use even as a tech-savvy person; if we want it to actually become popular as a web auth method, it has to start with better UX.

amelius 8y ago
Yes, see "PGP" for an example where good crypto tech fails when the UX is not on par.
parliament32 8y ago
To be fair the UX for client side certs is pretty idiotproof once you have the cert installed. You get a "X site is requesting an identity certificate" box. Installing certs is pretty painless too -- you navigate to a certain page and get a "this site is attempting to install a security identification certificate in your browser" box. Securely getting to that page is a different matter. As for logging in on untrusted devices (biz center, friend's PC, etc)... you shouldn't be doing that under any circumstances in a high security situation.
- dogma1138 8y ago
  The problem with certificates is that A) it requires the user to install them on every device B) they are required to be installed on every device C) they are a bitch to manage and distribute and D) protection around certificates is fairly weak and any client compromise will lead to the exposure of all credentials. You also end up delegating the authentication to your transport layer which is never that good of an idea.
  - elblanko 8y ago
    I think most linux distro's protection of certificate private keys is pretty weak (just storing a .pem file somewhere) and I can't say anything about OSX but on Windows you can prevent the private key from being disclosed even if the user wants to export it and enforce entering a password or PIN each time the certificate is used. Getting access to the physical hardware is about the only way to bypass the CryptoAPI, which is pretty far from 'any' client compromise.
    - tialaramex 8y ago
      You can't actually "prevent the private key from being disclosed even if the user wants to export it" out of box on Windows [if you have an HSM this may be an option although it may also make the keys unsuitable for some purposes]. You can make it _annoying_ which is a stock in trade for Microsoft designs, but attackers don't care about it being annoying. The reason is that the CryptoAPI hands over the keys to an application for it to use (it does not function only as a proxy like say ssh-agent), and so application can export the keys. People even make ready-to-use apps to do this, because, as described above, the CryptoAPI behaviour is annoying. You can require a password, but that's true for text files on a Linux system too. So why don't most people use a secret password to protect a file with a secret key inside it? Because it's yet more pointless busy work, again a stock in trade of Microsoft environments. Also, because this is so very annoying you don't need physical access but only console access, which you can of course get remotely, as otherwise administrators of the mountains of Windows servers set up this way couldn't type in all the passwords needed over RDP every day. (If you're lucky they are using an encrypted RDP session to do this...)
derefr 8y ago
> Client certs suffer from questions like "as a user, how do I handle multiple devices? Logging in from my phone? Logging in from the biz center at some hotel / my friend's phone / etc? I see this as a perfect case for "logging into your browser" (Chrome Sync/Firefox Sync/iCloud Safari Keychain sync/etc.) Why not have any issued client certs be global to your "browser account" rather than local to your device? The cert bundles can also be transferred and stored using end-to-end encryption (like iMessage keybags.) Sure, now you can't tell which of a person's devices they're on from just the cert you're seeing. That's what cookies or localStorage would be for, since they explicitly don't sync between devices. Client cert for AAA + session cookie for holding the server-side connection ID.

arkadiyt 8y ago

It still feels marginally better because it requires making a change that is visible to users, vs the normal case where a server can surreptitiously collect passwords. It also works nicely for the mobile app login case.

hinkley 8y ago

You want your browser to support PAKE, not for the website to send javascript. Lack of native browser support seems to be what held up SRP. Hopefully OPAQUE can make it farther.

tptacek 8y ago
It seems unlikely. The differences between OPAQUE and SRP aren't what kept SRP from being adopted. The fact that SRP doesn't really solve a problem that most organizations care about for their web applications is a bigger issue. Remember, virtually all mainstream applications accept logins over TLS (exclusively) at this point, so being able to authenticate and encrypt a channel with a passphrase isn't all that valuable. As a security engineer working for a startup, there aren't a lot of new features I'd be able to build after having adopted SRP, and essentially none of my real current challenges (credential stuffing, phishing) would get any easier. That's not to say OPAQUE isn't useful; it's just not that useful in SAAS-type application settings.
- gok 8y ago
  What about the "oops we accidentally logged passwords in plain text" issue mentioned in the article?
  - tptacek 8y ago
    I don't believe that's a security concern that motivates entire new protocols; further, I think it's one of those security issues that is talked about more than it is actually felt. So far as I know, none of the HIBP datasets have come from logs? I'd be interested in corrections. The "real" issue PAKEs address is long-term compromise, where an attacker can observe passwords out of memory. For that matter: for attackers to get log files in the first place, 9 times out of 10 they had to get RCE somewhere in prod, and that is already game over. And, there's a lot of things you'd do first do address game-over than replacing your TLS login POST with a PAKE handshake.
    - gok 8y ago

TimTheTinker 8y ago

You're assuming the client-side PAKE implementation must be provided by JS sent from the server. Why not implement a client-side PAKE API in the browser? It could be designed to disallow any server-sent code from accessing client credentials in plaintext, while still allowing styling and layout of credentials fields (this might be impossible, though). Or alternatively, let the browser handle the login/credentials UI, and build in a seamless password manager integration.

e12e 8y ago

Wasn't there talk about removing support for client side certs, either in the rfcs and/or major browsers? (citing ux problems) I can't seem to find any relevant links/bugs now though - maybe the decision was reversed? Or I'm simply wrong?