11 ms·

Let’s talk about PAKE

138 points by stargrave 8y ago

parliament32 8y ago
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?
lucb1e 8y ago
Usually this blog is very practical and easy to understand. This post, though, just talks about how great PAKE is and what this new proposal achieves, but not the how of it. It sounds better than client side hashing, but it doesn't explain how (or whether) that's achieved. Actually looking into PAKE is left as an exercise for the reader (other than one screenshot full of math at the bottom). Wikipedia is actually more clear in this case: > an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each (few) guesses. This means that strong security can be obtained using weak passwords. Looking into SRP, it seems that a server can still brute force a stored login. While cool, TLS achieves the same goal in popular login systems: eavesdroppers cannot learn anything (in fact, they cannot even make a single attempt at the password, unlike with PAKE). The other advantage of PAKE, the server never receiving the password, can be done with client side hashing (for which I've been advocating for years, as it would have prevented many issues).
- the_clarence 8y ago
  If you are an active server attacker, you can simply disable hashing and store passwords in clear. With SRP you cannot.
  - panopticon 8y ago
    Maybe this is naive, but if the server is compromised such that an attacker can circumventing your hashing function can't the attacker just send some JS down to the client that records the password before it's hashed?
    - tptacek 8y ago
      Yes, you can't securely deploy a PAKE using browser javascript. If it's web applications you want to secure, your users will have to install something to make a PAKE secure.
      - cipherboy 8y ago
cipherboy 8y ago
I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE... Kerberos has a draft for adding SPAKE to Kerberos: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-06 https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-prea... This was implemented sometime around March in MIT Kerberos: https://github.com/krb5/krb5/pull/741 https://github.com/krb5/krb5/pull/741 One of the interesting use cases would be to add 2FA support to the Kerberos protocol, but that support is still pending last I checked. A second draft that is useful for SPAKE would be improved Channel Binding (CBs) support: https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-01 https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-... CBs are still WIP upstream: https://github.com/krb5/krb5/pull/685 https://github.com/krb5/krb5/pull/685 Channel bindings allow Kerberos to piggy back on top of an existing encrypted channel (e.g., TLS). When doing 2FA with SPAKE in a browser, this means that we can take advantage of the security guarantees of the TLS protocol by ensuring the value of the final handshake is the same. This is most helpful for SSO-type scenarios. If anyone wants to comment on either RFC, I'm sure the Kitten WG would be happy to take feedback: https://tools.ietf.org/wg/kitten/ https://tools.ietf.org/wg/kitten/ Disclosure: I work closely with several of these folks and worked on the CBs PR.
- lvh 8y ago
  Is there a particular reason to use a symmetric PAKE in this case? Is it somehow not a long-held password?
forapurpose 8y ago
Without digging into this post too much ... is the problem that we don't know the solution, that servers aren't implementing it, that clients (browsers) are limited, or more than one of the above? To the degree that it's the browsers' limitations, couldn't the browser makers make a standard authentication client (or at least an API) with whatever tech and features are needed? A sandboxed mini-application, hardened, that passes a 'yes', 'no', or 'timeout' to the browser? Not every website would utilize it, but certainly the well-resourced ones could at first (FAANG, banks, etc.) and web server engines, frameworks, content management systems, etc. could incorporate the server side over time. It doesn't seem expensive, and the ROI would seem to enormous - safe authentication over the Internet. But maybe I'm solving the wrong problem?
- fileworm 8y ago
  There is such an API. It's called HTTP authentication. No one uses it.
lordnacho 8y ago
This bit I didn't get: > The earliest key exchange protocols — like classical Diffie-Hellman — were unauthenticated, which made them vulnerable to man-in-the-middle attacks. From Wikipedia (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...): > The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. Maybe there's something I'm not understanding, but I thought the point of DH was you could exchange something even when other people are listening. You can see in the example in the article that it does't matter what Eve can see.
- deathanatos 8y ago
  The other comments are all right, I just want to rephrase this is bit. Neither quotes are wrong, per se. This part: > Maybe there's something I'm not understanding, but I thought the point of DH was you could exchange something even when other people are listening DH does protect you against people listening. It doesn't help if they can actively change what you hear. Passive eavesdroppers are thwarted, but an active MitM attack is not, which is where authenticating the other end comes in. The common example of DH I've seen is that you can establish a secret key with someone in a crowded room, with everyone overhearing your conversation. In that example, our "authentication" is that we can visually see the other person and we recognize them (or at least, we want to communicate with that person).
- mike-cardwell 8y ago
  Without auth, you know you're doing DH, you just don't know who you're doing it with. If somebody is passively observing/recording the traffic, they wont know what the negotiated shared secret was. However, if they actively insert themselves in the middle, they can negotiate a shared key with you, and another one with the final destination. Then they can decrypt messages from you with the shared secret they negotiated with you, re-encrypt with the shared secret they negotiated with the other party and forward them on.
- eminence32 8y ago
  Alice and Bob think they are talking directly to each other. Instead, they are both talking to Eve (the "man" in the middle). Alice and Eve do DH exchange and agree upon a secret. Eve and Bob do a DH exchange and also agree upon a secret. Now Eve knows both these secrets and can relay messages between Alice and Bob. Both think they are talking securely to each other, but they are actually talking to Eve instead
dev_dull 8y ago
The reason it's not used more often is only because it's incrementally better than salted and memory-hard hashed passwords. It has obvious and important benefits, but still only incrementally better. It's more important that bad implementations are removed immediately. Personally I'd rather get rid of all of my passwords and use FIDO2 or perhaps even something through touch-id on my iOS/Mac. At this point every password I have is unique thanks to great password managers.
- DINKDINK 8y ago
  >Personally I'd rather get rid of all of my passwords and use FIDO2 FIDO2 should be implemented in many more areas but it shouldn't be exclusively relied on for authentication. Authentication should require proof of person/entity (something you have, a FIDO2 key) and proof of volition (using a password stored in their brain that their will decides to produce/disclose)
  - floatboth 8y ago
    > their will decides to produce/disclose Or someone else's will decides to shoulder-surf / keylog the password :)
- floatboth 8y ago
  USB/NFC tokens and phones/computers are all "loseable". There are cool ideas about backup tokens https://dmitryfrank.com/articles/backup_u2f_token https://dmitryfrank.com/articles/backup_u2f_token but IMO they can't be the only way to sign in, there should be some way to restore access from nothing (I guess my specific paranoia is about being locked out :D) There are many specific auth "factors": - valid signature from an extrernal hardware token (U2F/WebAuthn via e.g. YubiKey) - valid signature from a device's embedded token/TPM (something like Touch ID / Windows Hello / Android keystore thing) - … as a WebAuthn implementation - … in response to a push notification on another device (Twitter, if they still have that) - … in response to a QR code (SQRL, Yandex.Key) - one-time code via push notification to another device (Apple) - one-time code generated from a shared secret key (TOTP) - one-time sign-in link via email (Tumblr) - passwords - secret questions (like extra passwords but worse) - behavior pattern analysis (IIRC Google showed an Android demo that looked at keyboard typing patterns and whatnot) A good auth system should combine multiple factors in a correct way to minimize both impersonation and lockout chances, and maximize usability. How? That's the challenge…
Zash 8y ago
Shout out to SCRAM (RFC 5802) which enables hashed password storage on both the client and the server.
- tptacek 8y ago
  Aren't you shouting out to a protocol that is in every material sense worse than a PAKE?
zokier 8y ago
I wonder if "Don't do password-authenticated key exchange." is still "Cryptographic right answer"; does OPAQUE address the reservations that tptacek had back in the day https://news.ycombinator.com/item?id=9593916#9594731 https://news.ycombinator.com/item?id=9593916#9594731
- tptacek 8y ago
  No, not at all. OPAQUE addresses problems Green has with SRP, not the problems I have.
  - aidenn0 8y ago
    WPA-3 is using a PAKE, ignoring the fact that there are some concerns about the specific PAKE used, do you think a PAKE buys anything in that use case?
    - lvh 8y ago
      It's pretty decent for the WiFi use case, but you could actually do something cooler with a symmetric PAKE if your WiFi device had a display. Pick a short random password, copy it over to the client, do SPAKE2. You now have a unique, high entropy secret -- and you have strong guarantees no-one else has that secret (an attacker can guess, but there's a tiny time window for them to do so, and the honest participants are immediately convinced foul play occurred). As it stands, the PAKE is better than what they had, but not ridiculously better in the way U2F is over TOTP for example.
  - fileworm 8y ago
    OK, what are the problems you have with password-authenticated key exchange?
helper 8y ago
One place where PAKEs are widely deployed is in enterprise wifi networks that use PEAP/MSChapV2 password auth. MSChapV2 is really terrible and basically requires you to store passwords with weak hashes (or in cleartext). Its nice to hear that there are PAKEs that are not tied to specific password hashing functions.
- tptacek 8y ago
  The WPA2 4-way handshake isn't great, but a PAKE actually doesn't do too much --- besides breaking the (slow) dictionary attack --- to operationally improve its security. PAKEs are a good fit for wifi handshakes, if you're starting from zero.
jedisct1 8y ago
Related and maybe more accessible: https://00f.net/2018/10/18/on-user-authentication/ https://00f.net/2018/10/18/on-user-authentication/
- nmadden 8y ago
  We have been looking at something very similar (using scrypt and Ed25519) at work for LDAP (SASL) authentication. The primary motivation for us is to move costly password hashing off the LDAP servers. Our current design is basically the same, but we generate and store a random salt server-side and present that to the client along with the challenge. Using a deterministic salt based on the username and domain is a nice idea - we actually do something similar if the client presents an incorrect username to avoid leaking whether the account exists (we send salt = HMAC(secret, username) in that case).
deleted 8y ago
[deleted]
gpm 8y ago
Something I've never understood is why we don't hash the password on the client before sending it to the server, and again on the server. This prevents the server from knowing your password (assuming it's a good one) with no real drawbacks that I can see.
- Ar-Curunir 8y ago
  This provides no real defence against dictionary attacks; the attacker's work just doubles.
  - gpm 8y ago
    No, it doesn't. It does however provide defense against taking over the server, stealing everyone's passwords, and using them on other servers. I'm assuming, and I suppose I should have stated above, that the first hash is salted with something like the domain name. Even if not it provides the same level of protection for password generation schemes.
- deleted 8y ago
  [deleted]
- caf 8y ago
  Because then the hash of the password becomes equivalent to a password - a malicious actor that learns the hash of the password can just use that to log in to the service (since they can just choose to send it to the server).
  - gpm 8y ago
    You're absolutely right. But it means that they can't use the password to build a dictionary, to log in to other services, etc. (Assuming the password is complex enough that the hash isn't reversible)
anon49124 8y ago
Btw, correct me if I'm wrong regarding extendable output hash functions: Keccak instances of SHAKE are XOF, which allow varying lengths of output hashes rather than fixed-sized output of the predefined SHA3 instances?
qrv3w 8y ago
For a more technical references check out Dan Boneh and Victor Shoup's cryptography book (pg 789). [0] For the Gophers out there, I wrote a Go library for doing PAKE [1], which I use for a data transfer utility [2]. [0]: https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.... [1]: https://github.com/schollz/pake https://github.com/schollz/pake [2]: https://github.com/schollz/croc https://github.com/schollz/croc
lvh 8y ago
I'm really excited about PAKEs! But for a totally different reason. PAKEs are great for low-entropy secrets, but they don't have to be static: you can generate them on the fly too. Every time you have a human-mediated channel that eventually needs to agree on a strong secret, PAKEs are good. So, if you have a device that you want to pair with an existing device with an untrusted third party PAKEs are super great. You can use this to safely send a file across the ether by just sharing a short string like "2-bonobo-magic; see magic-wormhole. I therefore disagree with the notion that a PAKE being symmetric is a downside: I just think that they're different tools for different tasks, and we should talk about sPAKEs and aPAKEs specifically. Symmetric PAKEs are worse for password auth: I just think PAKEs are not a high priority for password auth. There are two problems with passwords: cred stuffing and phishing (fundamentally the same attack: an attacker gets a password "out of band" and then replays it) and PAKEs solve neither. [magic-wormhole]: https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole

138 points by stargrave 8y ago

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?

lucb1e 8y ago

Usually this blog is very practical and easy to understand. This post, though, just talks about how great PAKE is and what this new proposal achieves, but not the how of it. It sounds better than client side hashing, but it doesn't explain how (or whether) that's achieved. Actually looking into PAKE is left as an exercise for the reader (other than one screenshot full of math at the bottom). Wikipedia is actually more clear in this case: > an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each (few) guesses. This means that strong security can be obtained using weak passwords. Looking into SRP, it seems that a server can still brute force a stored login. While cool, TLS achieves the same goal in popular login systems: eavesdroppers cannot learn anything (in fact, they cannot even make a single attempt at the password, unlike with PAKE). The other advantage of PAKE, the server never receiving the password, can be done with client side hashing (for which I've been advocating for years, as it would have prevented many issues).

the_clarence 8y ago
If you are an active server attacker, you can simply disable hashing and store passwords in clear. With SRP you cannot.
- panopticon 8y ago
  Maybe this is naive, but if the server is compromised such that an attacker can circumventing your hashing function can't the attacker just send some JS down to the client that records the password before it's hashed?
  - tptacek 8y ago
    Yes, you can't securely deploy a PAKE using browser javascript. If it's web applications you want to secure, your users will have to install something to make a PAKE secure.
    - cipherboy 8y ago

cipherboy 8y ago

I'll shamelessly plug this for Kerberos since SPAKE is a variant of PAKE... Kerberos has a draft for adding SPAKE to Kerberos: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-06 https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-prea... This was implemented sometime around March in MIT Kerberos: https://github.com/krb5/krb5/pull/741 https://github.com/krb5/krb5/pull/741 One of the interesting use cases would be to add 2FA support to the Kerberos protocol, but that support is still pending last I checked. A second draft that is useful for SPAKE would be improved Channel Binding (CBs) support: https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-01 https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-... CBs are still WIP upstream: https://github.com/krb5/krb5/pull/685 https://github.com/krb5/krb5/pull/685 Channel bindings allow Kerberos to piggy back on top of an existing encrypted channel (e.g., TLS). When doing 2FA with SPAKE in a browser, this means that we can take advantage of the security guarantees of the TLS protocol by ensuring the value of the final handshake is the same. This is most helpful for SSO-type scenarios. If anyone wants to comment on either RFC, I'm sure the Kitten WG would be happy to take feedback: https://tools.ietf.org/wg/kitten/ https://tools.ietf.org/wg/kitten/ Disclosure: I work closely with several of these folks and worked on the CBs PR.

lvh 8y ago
Is there a particular reason to use a symmetric PAKE in this case? Is it somehow not a long-held password?

forapurpose 8y ago

Without digging into this post too much ... is the problem that we don't know the solution, that servers aren't implementing it, that clients (browsers) are limited, or more than one of the above? To the degree that it's the browsers' limitations, couldn't the browser makers make a standard authentication client (or at least an API) with whatever tech and features are needed? A sandboxed mini-application, hardened, that passes a 'yes', 'no', or 'timeout' to the browser? Not every website would utilize it, but certainly the well-resourced ones could at first (FAANG, banks, etc.) and web server engines, frameworks, content management systems, etc. could incorporate the server side over time. It doesn't seem expensive, and the ROI would seem to enormous - safe authentication over the Internet. But maybe I'm solving the wrong problem?

fileworm 8y ago
There is such an API. It's called HTTP authentication. No one uses it.

lordnacho 8y ago

This bit I didn't get: > The earliest key exchange protocols — like classical Diffie-Hellman — were unauthenticated, which made them vulnerable to man-in-the-middle attacks. From Wikipedia (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...): > The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. Maybe there's something I'm not understanding, but I thought the point of DH was you could exchange something even when other people are listening. You can see in the example in the article that it does't matter what Eve can see.

deathanatos 8y ago
The other comments are all right, I just want to rephrase this is bit. Neither quotes are wrong, per se. This part: > Maybe there's something I'm not understanding, but I thought the point of DH was you could exchange something even when other people are listening DH does protect you against people listening. It doesn't help if they can actively change what you hear. Passive eavesdroppers are thwarted, but an active MitM attack is not, which is where authenticating the other end comes in. The common example of DH I've seen is that you can establish a secret key with someone in a crowded room, with everyone overhearing your conversation. In that example, our "authentication" is that we can visually see the other person and we recognize them (or at least, we want to communicate with that person).
mike-cardwell 8y ago
Without auth, you know you're doing DH, you just don't know who you're doing it with. If somebody is passively observing/recording the traffic, they wont know what the negotiated shared secret was. However, if they actively insert themselves in the middle, they can negotiate a shared key with you, and another one with the final destination. Then they can decrypt messages from you with the shared secret they negotiated with you, re-encrypt with the shared secret they negotiated with the other party and forward them on.
eminence32 8y ago
Alice and Bob think they are talking directly to each other. Instead, they are both talking to Eve (the "man" in the middle). Alice and Eve do DH exchange and agree upon a secret. Eve and Bob do a DH exchange and also agree upon a secret. Now Eve knows both these secrets and can relay messages between Alice and Bob. Both think they are talking securely to each other, but they are actually talking to Eve instead

dev_dull 8y ago

The reason it's not used more often is only because it's incrementally better than salted and memory-hard hashed passwords. It has obvious and important benefits, but still only incrementally better. It's more important that bad implementations are removed immediately. Personally I'd rather get rid of all of my passwords and use FIDO2 or perhaps even something through touch-id on my iOS/Mac. At this point every password I have is unique thanks to great password managers.

DINKDINK 8y ago
>Personally I'd rather get rid of all of my passwords and use FIDO2 FIDO2 should be implemented in many more areas but it shouldn't be exclusively relied on for authentication. Authentication should require proof of person/entity (something you have, a FIDO2 key) and proof of volition (using a password stored in their brain that their will decides to produce/disclose)
- floatboth 8y ago
  > their will decides to produce/disclose Or someone else's will decides to shoulder-surf / keylog the password :)
floatboth 8y ago
USB/NFC tokens and phones/computers are all "loseable". There are cool ideas about backup tokens https://dmitryfrank.com/articles/backup_u2f_token https://dmitryfrank.com/articles/backup_u2f_token but IMO they can't be the only way to sign in, there should be some way to restore access from nothing (I guess my specific paranoia is about being locked out :D) There are many specific auth "factors": - valid signature from an extrernal hardware token (U2F/WebAuthn via e.g. YubiKey) - valid signature from a device's embedded token/TPM (something like Touch ID / Windows Hello / Android keystore thing) - … as a WebAuthn implementation - … in response to a push notification on another device (Twitter, if they still have that) - … in response to a QR code (SQRL, Yandex.Key) - one-time code via push notification to another device (Apple) - one-time code generated from a shared secret key (TOTP) - one-time sign-in link via email (Tumblr) - passwords - secret questions (like extra passwords but worse) - behavior pattern analysis (IIRC Google showed an Android demo that looked at keyboard typing patterns and whatnot) A good auth system should combine multiple factors in a correct way to minimize both impersonation and lockout chances, and maximize usability. How? That's the challenge…

Zash 8y ago

Shout out to SCRAM (RFC 5802) which enables hashed password storage on both the client and the server.

tptacek 8y ago
Aren't you shouting out to a protocol that is in every material sense worse than a PAKE?

zokier 8y ago

I wonder if "Don't do password-authenticated key exchange." is still "Cryptographic right answer"; does OPAQUE address the reservations that tptacek had back in the day https://news.ycombinator.com/item?id=9593916#9594731 https://news.ycombinator.com/item?id=9593916#9594731

tptacek 8y ago
No, not at all. OPAQUE addresses problems Green has with SRP, not the problems I have.
- aidenn0 8y ago
  WPA-3 is using a PAKE, ignoring the fact that there are some concerns about the specific PAKE used, do you think a PAKE buys anything in that use case?
  - lvh 8y ago
    It's pretty decent for the WiFi use case, but you could actually do something cooler with a symmetric PAKE if your WiFi device had a display. Pick a short random password, copy it over to the client, do SPAKE2. You now have a unique, high entropy secret -- and you have strong guarantees no-one else has that secret (an attacker can guess, but there's a tiny time window for them to do so, and the honest participants are immediately convinced foul play occurred). As it stands, the PAKE is better than what they had, but not ridiculously better in the way U2F is over TOTP for example.
- fileworm 8y ago
  OK, what are the problems you have with password-authenticated key exchange?

helper 8y ago

One place where PAKEs are widely deployed is in enterprise wifi networks that use PEAP/MSChapV2 password auth. MSChapV2 is really terrible and basically requires you to store passwords with weak hashes (or in cleartext). Its nice to hear that there are PAKEs that are not tied to specific password hashing functions.

tptacek 8y ago
The WPA2 4-way handshake isn't great, but a PAKE actually doesn't do too much --- besides breaking the (slow) dictionary attack --- to operationally improve its security. PAKEs are a good fit for wifi handshakes, if you're starting from zero.

jedisct1 8y ago

Related and maybe more accessible: https://00f.net/2018/10/18/on-user-authentication/ https://00f.net/2018/10/18/on-user-authentication/

nmadden 8y ago
We have been looking at something very similar (using scrypt and Ed25519) at work for LDAP (SASL) authentication. The primary motivation for us is to move costly password hashing off the LDAP servers. Our current design is basically the same, but we generate and store a random salt server-side and present that to the client along with the challenge. Using a deterministic salt based on the username and domain is a nice idea - we actually do something similar if the client presents an incorrect username to avoid leaking whether the account exists (we send salt = HMAC(secret, username) in that case).

deleted 8y ago

[deleted]

gpm 8y ago

Something I've never understood is why we don't hash the password on the client before sending it to the server, and again on the server. This prevents the server from knowing your password (assuming it's a good one) with no real drawbacks that I can see.

Ar-Curunir 8y ago
This provides no real defence against dictionary attacks; the attacker's work just doubles.
- gpm 8y ago
  No, it doesn't. It does however provide defense against taking over the server, stealing everyone's passwords, and using them on other servers. I'm assuming, and I suppose I should have stated above, that the first hash is salted with something like the domain name. Even if not it provides the same level of protection for password generation schemes.
deleted 8y ago
[deleted]
caf 8y ago
Because then the hash of the password becomes equivalent to a password - a malicious actor that learns the hash of the password can just use that to log in to the service (since they can just choose to send it to the server).
- gpm 8y ago
  You're absolutely right. But it means that they can't use the password to build a dictionary, to log in to other services, etc. (Assuming the password is complex enough that the hash isn't reversible)

anon49124 8y ago

Btw, correct me if I'm wrong regarding extendable output hash functions: Keccak instances of SHAKE are XOF, which allow varying lengths of output hashes rather than fixed-sized output of the predefined SHA3 instances?

qrv3w 8y ago

For a more technical references check out Dan Boneh and Victor Shoup's cryptography book (pg 789). [0] For the Gophers out there, I wrote a Go library for doing PAKE [1], which I use for a data transfer utility [2]. [0]: https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.... [1]: https://github.com/schollz/pake https://github.com/schollz/pake [2]: https://github.com/schollz/croc https://github.com/schollz/croc

lvh 8y ago

I'm really excited about PAKEs! But for a totally different reason. PAKEs are great for low-entropy secrets, but they don't have to be static: you can generate them on the fly too. Every time you have a human-mediated channel that eventually needs to agree on a strong secret, PAKEs are good. So, if you have a device that you want to pair with an existing device with an untrusted third party PAKEs are super great. You can use this to safely send a file across the ether by just sharing a short string like "2-bonobo-magic; see magic-wormhole. I therefore disagree with the notion that a PAKE being symmetric is a downside: I just think that they're different tools for different tasks, and we should talk about sPAKEs and aPAKEs specifically. Symmetric PAKEs are worse for password auth: I just think PAKEs are not a high priority for password auth. There are two problems with passwords: cred stuffing and phishing (fundamentally the same attack: an attacker gets a password "out of band" and then replays it) and PAKEs solve neither. [magic-wormhole]: https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole