[tialaramex]

Others have explained what's really going on here, but I want to take a moment to address this idea that they don't "have my passwords" because that's illuminating too.

In a very real sense most of these systems, almost everything on the web today, do have your password, though that wasn't necessarily the direct cause of the problem here.

Passwords in this context are a shared secret. You remember your Google password is hunter2, you send that password to Google's web server to log in, they check, yup, hunter2 is the password, OK.

For 50+ years we've had these slightly goofy strategies with these shared secrets, which if you have a good password (so, not hunter2) and Google implement the strategy well, mean that at rest they don't really know your password. But still every single time you authenticate, you are sending them your password, and when that happens you both know what it is† - this means for example they could accidentally publish it, record it to a log, or anything else.

For less time, but still decades, we've known how to build an Augmented PAKE. With this technology, you can prove to (say) Google that you know some password, and then later, that you still know the same password, yet Google never learns what the password is - which means that even if they really wanted to they can't tell anybody else - all they can do is check that you still know your password, which is in fact the thing we actually wanted.

Nevertheless, here we are in 2025, and judging from previous times I've explained this, HN will insist that the schemes which haven't worked are a great idea and there's no reason to use an Augmented PAKE.

† As does anybody who can read the messages, which in 2025 is usually nobody else, but say 10-20 years ago was usually anybody on the path, e.g. your ISP.

[tptacek]

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.

[tialaramex]

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.

[tptacek]

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.

[tialaramex]

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.

[tptacek]

Yes, we did! RC4 is a great example of what I'm talking about. It's a cipher nobody had any business ever using, and we were using it well into the 2010s, despite the fact that the (comically simple) underlying vulnerabilities in it were known in the 1990s.

[tialaramex]

How is RC4 a great example? Obviously with hindsight you'd choose something different, but in the mid-1990s there wasn't a lot of good options - in your alternate history do we just hope DES (which we know has a NOBUS for the US government) is OK forever? Do we go without SSL altogether ? What's the plan ?

[stock_toaster]

We also have passkeys now too.