(2018)
Prior commentary:
Let’s Talk about PAKE (2018)
31–40 of 70 posts
Re: Let’s Talk about PAKE (2018)
#32Earlier 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…
Are you sure that's how Matrix E2EE works? In my experience, to access encrypted chats after logging in for the first time I have to verify the new session by performing a synchronous prompt-verify sequence from an existing session, and I don't remember setting any encryption passphrase at all.
What gives? Are we just using different defaults or clients or something?
Re: Let’s Talk about PAKE (2018)
#33Earlier 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…
Are you sure that's how Matrix E2EE works? In my experience, to access encrypted chats after logging in for the first time I have to verify the new session by performing a synchronous prompt-verify sequence from an existing session, and I don't remember setting any encryption passphrase at all. What gives? Are we just using different defaults or clients or something?
Disclaimer: I'm not an expert in this stuff, just a 3rd party client developer who is interested in the topic.
AFAIK, there are two ways to validate a new device in Matrix.
It sounds like you're describing the interactive device validation procedure. After that, your two devices trust each other, and the old device can "cross sign" the public key of your new device, so others can trust it too.
Personally for me, even with cross-signing, I was still getting a significant number of messages that failed to decrypt. Usually I think the problem was that one of my devices wasn't around to receive the original version of some key. And for whatever reason, even with cross-signing, it wasn't getting the keys from my other devices. For example, maybe my other devices were offline at the time.
The fix for me was to go the passphrase route. Now, regardless of what device I'm on, the passphrase gets me access to all of my secrets via the encrypted blob on the server.
Re: Let’s Talk about PAKE (2018)
#34Earlier quoted context omitted.
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.
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.
Re: Let’s Talk about PAKE (2018)
#35I 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…
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.
Re: Let’s Talk about PAKE (2018)
#36WhatsApp’s encrypted backups use OPAQUE. Source: https://scontent.whatsapp.net/v/t39.8562-34/241394876_546674...
Re: Let’s Talk about PAKE (2018)
#37What is the benefit of PAKE over this: https://datatracker.ietf.org/doc/html/rfc2289
Re: Let’s Talk about PAKE (2018)
#38I 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…
There's a simpler protocol SCRAM based on just a hash function and similarly doesn't send a cleartext password.
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.
Re: Let’s Talk about PAKE (2018)
#39Earlier quoted context omitted.
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.
FWIW there's an experimental RFC 7804, but I don't know if any browser implemented it.
Re: Let’s Talk about PAKE (2018)
#40[deleted]