So, OPAQUE stands for what? Or, do we not care anymore? :) Apparently, it's based on "aPAKE" which stands for "Asymmetric PAKE", but I guess OPAQUE is an acronym that sounds cool.
Let’s Talk about PAKE (2018)
21–30 of 70 posts
Re: Let’s Talk about PAKE (2018)
#22Earlier quoted context omitted.
There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.
Even if it's conceptually simpler, it still suffers from the same issues in my comment
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.
Re: Let’s Talk about PAKE (2018)
#23Earlier quoted context omitted.
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 thi…
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.
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.
Re: Let’s Talk about PAKE (2018)
#24Earlier quoted context omitted.
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.
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.
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.
Re: Let’s Talk about PAKE (2018)
#25Earlier quoted context omitted.
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.
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.
> 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.
Re: Let’s Talk about PAKE (2018)
#26Relatedly, a recent post on SRP (the most commonly used PAKE) and how it's worse in all cases than PAKEs derived from SPEKE: https://tobtu.com/blog/2021/10/srp-is-now-deprecated/
So the two main problems with SRP, according to this post, are:
1. It exposes the salt and verifier to the adversary, enabling a brute-force search for the password
2. It relies on the discrete log problem, and is thus vulnerable to quantum computers
In practice, I don't buy the argument that either one of these is a deal breaker, as long as you do SRP in a "modern" way, ie you're not tied verbatim to some 1997 version of the spec.
For #1, if you hash the password with a decent password hashing function (bcrypt/scrypt/argon2) with a reasonable work factor, then only the dumbest/worst passwords are at risk of being cracked in any reasonable amount of time. Notice that the password hashing happens entirely on the client, so you can crank that work factor up pretty high.
For #2, if somebody builds a huge quantum computer big enough to take on these problems, then we are so freaking screwed in so many other ways. SRP logins will be the least of our concerns.
Not to take away from EKE and its derivatives in any way. I've been a huge fan of the original Bellovin & Merritt construction since I first read about it 20 years ago.
Re: Let’s Talk about PAKE (2018)
#27I 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…
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 thi…
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.
Re: Let’s Talk about PAKE (2018)
#28Earlier quoted context omitted.
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 thi…
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 sessio…
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).
Re: Let’s Talk about PAKE (2018)
#29Earlier quoted context omitted.
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 sessio…
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).
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?
Re: Let’s Talk about PAKE (2018)
#30Earlier quoted context omitted.
Even if it's conceptually simpler, it still suffers from the same issues in my comment
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.
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.