undefined | Better HN

0 pointstptacek1y ago0 comments

We have not had augmented PAKEs that were widely trusted by the cryptographic engineering community for decades. OPAQUE was 2018. The adoption you're looking for hasn't happened for a bunch of reasons, including:

* The industry's (reasonable) emphasis on moving people away from passwords altogether, and towards phishing-proof authentication.

* The fact that we'd have to do new underlying protocol work to meaningfully get the benefit you're talking about --- you can't just do it in Javascript, because you're talking about "server-proofing" logins, a threat model that presumes the attacker controls the server's login flow.

* Just the baseline fact that "losing passwords directly from Apple and Google and Meta authentication servers" hasn't been a driver of account takeovers, and you will never get PAKE adoption from the kinds of providers who do drive these incidents.

PAKEs are just a technology cryptography nerds fall in love with and want to find use cases for. I like them too! Build more things like Magic Wormhole. Don't get grumpy when the entire web doesn't wrap itself around them.

0 comments

3 comments · 1 top-level

tialaramex1y ago· 2 in thread

My Google account is indeed protected with Yubikeys and so on. Years after I bought my first Security Key, I can name all the places I use it, whereas if I type 'pass' the list goes on for several screens.

But while it's true that OPAQUE is what you might choose today, SRP is much older. We didn't have AES in 1995, we certainly didn't have a workable AEAD but instead of waiting for 21st century technology Netscape shipped SSL - very flawed but points in the correct direction.

The web actually went backwards in a sense. HTTP is designed with an authentication layer, but it's not up to the task for modern systems so nobody uses it in user facing software, only some APIs.

This feels like a theme - we can have better things, improvement is possible. "Oh well, it's never getting any better than this" isn't quite as stupid as "Nothing could be worse" (followed often very shortly by the discovery that you've underestimated how bad it could get e.g. electing the "outsider" and then electing him against now he's a felon) but it's still a mistake.

As you may know I have a habit of re-reading old stuff I wrote, one of the classics is from when Let's Encrypt launched and I'm explaining to Peter Gutmann about ACME. Peter's take is that we shouldn't make these protocols at all, they're a waste of time, and if we want one SCEP already exists. As you know, ACME has been an enormous success, but at the time this was not obvious. Peter was assuming that it's never getting any better, but it actually got almost unrecognisably better and quite quickly.

tptacekOP1y ago

Right. I like SRP. I've implemented it many times. It's also a personal favorite because it coughs up amazingly good vulnerabilities (it's not often a dumb crypto implementation bug gets you a full auth bypass).

But cryptographers did not generally like SRP. Lots of cryptographers had misgivings about it. It is not surprising to me that SRP didn't get usefully baked into the web.

This "HTTP is designed with an authentication layer" stuff is a very old argument on HN. There are two sides to it. The other side is: baking stuff directly into the protocol makes us path-dependent on what we decide to add (see: every protocol ever designed), and if we were path dependent on 2002-era cryptography, that would be a very bad thing. Authentication is a complicated problem and people's needs differ.

I respect the take, the same way I enjoy reading Gutmann even though I agree with only like 50% of what he says.

tialaramex1y ago

Again I'm not here to praise SRP, though I will mention that when I think of you and and dumb crypto for a full bypass I always think of your surprise that Microsoft shipped a broken ECC implementation in Windows some years back. It's hard to dig a pit of success deep enough that everybody falls in, and that's why I like systems where we don't tell people things they don't need in the first place.

We didn't end up path dependant on RC4 for example, even though it's in SSLv2. RC4 is similar to SRP in some ways because nobody was ever comfortable with it but people kept trying to patch the known issues until eventually we gave up on it entirely.

1 more reply

j / k navigate · click thread line to collapse