[scrollaway]

I remember being a kid on the internet 20-something years ago, understanding how passwords worked, and thinking the whole of the internet must be crazy for accepting a "pinky-promise we don't store that secret password you're sending us in plaintext, let alone use it for nefarious purposes" as the status quo.

I then discovered SSH and how it worked, asked in some public forum why there isn't a way to log in to websites using an ssh keypair, and was ridiculed for it.

Ah well, glad times change.

[pmontra]

I defend against that scenario by letting my password manager generate a different random password for every site. It defends also against sites handling passwords in terribly wrong ways, hacks, leaks, etc.

[diggan]

> I then discovered SSH and how it worked, asked in some public forum why there isn't a way to log in to websites using an ssh keypair, and was ridiculed for it.

In an alternative universe, the web standardized something like "tripcodes but cryptographically secure" which would keep any secrets out from servers, and we'd just be dealing with signed data.

One could always dream :)

[brazzy]

Client certificates are a thing and can in principle be used for authentication on websites. Not 100% sure that was possible 20 years ago, but Istrongly suspect that it was.

The problem is the UX around handling the certificates. Password are nearly impossible to beat in terms of "works everywhere without requiring any support infrastructure".

[skydhash]

Even with SSH, you need access to the console when things went awry. But that’s easier to secure as you need to be physically present in front of the machine, or go through your cloud provider’s security mechanism.

But that’s only inconvenient when you want access back. Most B2C don’t care about you enough to offer those processes.