If we can use SSH to log in on servers, why can't we use it to log in on websites?

@yarmo People in professional setting frequently are unable to keep hygiene around private keys. What chance normies have?

@jb @yarmo Would it be worse than password authentication? Users love to write those down, unless they're allowed to use extremely bad ones that are easy to crack.

Ramblings follow...

A privkey on your PC that you load into your browser to have it identify you on any website you want to register at would be a very neat idea IMO.

It eliminates entire classes of very common security issues:

1. It eliminates the issue of websites having their password databases leaked, since those will just be databases of public keys instead. Even a DB of salted password hashes can be "mined" for login data with enough time and computing power; with public keys it's practically impossible.

2. Phishing is no more, since you never send a password to a website. Instead, your browser proves your identity by using the priv key to decrypt a challenge that the website encrypted with your pub key.

Possible disadvantages:

1. Registering with the same public key on many websites means that you're easily identifiable across them. However, this could be solved by using a key-bundle format standardized across browsers, where the browser automatically adds a new key to the bundle for every domain.

2. It might be easier for a piece of malware that makes itself onto a PC to just copy a key-bundle and upload it to a server, than to sniff out a password as it's typed into some website. But we already accept this risk with our SSH keys; generally we consider ourselves completely screwed anyway if malware makes it onto our PC.

The more I think about it, the more I wonder why such a technology hasn't long been standardized for the web. Ugh.

@socjuswiz good overview of pros and cons. I agree passwords are already being butchered so it could be worth the shot.

Tooling exists for passwords (managers) and are generally not used.

Mayyyyyybe with proper tooling, normies can safely use keys? Humongous "maybe", naive also. But maybe


@socjuswiz @jb @yarmo Regarding the 2nd disadvantage: you can password-protect your SSH keys, so even though the file is leaked the usefulness can be somewhat limited.

I guess the final UI will look about the same as current ones where the user enters username/password combination, but now all the action happens locally, without the password being transmitted.
- - - - -
There's also a third disadvantage, UI-wise: it's harder to log yourself on when you're changing machines, unless you use a portable key bundle device like one of those fancy dongles or smartcards :02lurk:

@koakuma @jb @yarmo

I'm trying to think in normie terms, and having to use a password at all is really difficult for them, so I think a passwordless key bundle would be the norm, but yeah, there should be an option to have both the bundle and individual keys within it password protected.

Good point on the third disadvantage. I wish those key card things where the privkey can't actually be read out of the card were much more widely available. I've never even seen one myself.

In the meantime, a USB stick would do. Browsers could be designed such that they never copy keys/bundles into their own storage; they'd always just use the file you pointed to. This way, as soon as you remove the USB drive, the browser on the foreign machine can't access the keys anymore. (If you distrust the machine, the point is moot, because it could as well have a keylogger. Only those special key cards can protect you in the situation where you want to use your key on an untrusted machine.)

@yarmo Did I understand it correctly that there is a (work-in-progress?) permission-based spec for browsers to implement filesystem access via JavaScript?

If that's the case, then a Javascript-prototype could be possible that can access ~/.ssh/* identities and certificates without the need of extensions or another daemon-process (not including e.g. ssh-agent).

For a proper implementation the browser should provide really secure access control so websites cannot access the wrong identities.

@yarmo That's only for a prototype though, to see how well this idea works and to move on from that.

However, regarding security considerations, my toenails roll up when I'm thinking more about having a browser access my ~/.ssh/ directory.

@yarmo you can login to ssh using FIDO2/U2F which also works on some websites. While this technically isn't a website login using ssh keys, it might come close to what you want to do.

isn't that basically for example Apache Server Client Certificate Authentication? See for example CACert's instructions

@yarmo And let measely consumers have access to public key cryptography? How are us noble businessmen going to keep squeezing them for everything they're worth, if we're not constantly finding ways to misdirect them from protecting themselves?

@yarmo AFAIK you can already use TLS certs for that - didn't see anyone ever using it, though...

@phel @yarmo Gemini uses client TLS certificates. Section 4.3:

One of the better reasons to use Gemini, IMHO.

@phel @yarmo yes, SSL/TLS cert auth and verification of clients works pretty much the same as the one for servers.

Much less used because it's rather fussy, but it's nothing new.

The problem is the whole cert management thing (for users especially).

@renatoram @phel @yarmo

Given the endless bitching about how awful and user hostile cryptography software is, this fact speaks volumes.

And here's what it speaks to me: A great deal of the trouble people have with cryptographic software isn't just because the design, the UX, the interfaces are (though, they often are horrible too). It's because the underlying structure of it all is just inherently tricky no matter what.

@renatoram @phel @yarmo

at some level, widespread use of client certs would make the user experience so much better and safer than the current model of "here have the browser or operating system hold cleartext copies of passwords for every last thing you have to identify for on the Internet". It would be loads better than biometrics and a lot of the multi-factor circus in favor today. It might not elimate it all, but it would be better.

@renatoram @phel @yarmo

but trying to make it all work means dealing with the *inherent* trickiness of it all.

It's not just a question of rounding corners and picking typefaces and color schemes and gamifying a bunch of interface options.

@vt @phel @yarmo frankly... A "personal keyring of certs" *could* definitely be managed in a more user friendly way, and maybe even be external to the browser, with a simple API, or whatever... But it's already hard enough to convince users to use sensible passwords: the resistance from users would be very hard to overcome.


I guess it depends on how it's done. When some entity out there says "you need to do this to reach this resource" my resistance means less than nothing to them, apparently.

I get enrolled in all sorts of multifactor or multifactor-like things all the time, in part because passwords are inadequate in so many ways. I'd rather there be some certificate option operating within some sort of known, if not standardized, context.

@phel @yarmo


and I'd rather have people who *claim* to be concerned for the user and for good interfaces working on filing off the rough edges

@phel @yarmo


case in point, logging in to this fediverse instance, if my interaction doesn't meet some set of criteria, criteria about which I know very little*, I'm asked to fetch a code from the email I used at registration and enter it as a second step.

I'd much rather there be some standard there for using password and user certificate.

* only guessing it is looking for cookies and at some sort of interaction date

@phel @yarmo

@yarmo The #WebAuthn standard does basically that: enable public-key authentication on the web.

@yarmo a website could generate a random hex, set a timeout and tell the user to sign it with the SSH key and paste the signature before the timeout expires. One time password.

@epilys precisely. With a bit of tooling around it, could be quite frictionless!

Worth a PoC

@yarmo @epilys so like TOTP without sharing the secret? In fact why doesn’t TOTP work this way already? I think it’s a good question.

force the user to sign the current time with a private key
server verifies using shared public key

That way, the secret can’t be obtained – even if the login server gets hacked.

@mwt @yarmo I was thinking about this process, only with SSH keys instead (see the diagram)

@epilys @yarmo that makes perfect sense, but using the time as the signable data would allow people to use a separate, possibly offline, device to get the codes.

You would want this if you were, for example, logging into a public machine.

@yarmo Ready :)

A bit of PITA as user experience goes, but that was expected. Piping the sig to xclip is a small improvement

@yarmo Well, there are TLS client certificates for TLS client authentication. Back in the day Firefox had pretty okay support for those. But I haven't seen any of those in use for ages.

@yarmo i'm just developing an in-browser website editor by which you publish the changes by signing it by your RSA key (all in-browser, client side).

@hbandi do you sign the changes in the CLI or do you "upload" the private key, even if its client side?

@yarmo the user drops the file (with his private key in it) in a form, but it does not upload, rather signs data locally by JS. i admit it's a bad idea to teach users to drop their private keys in arbitrary web page, but is does not differ a lot from situations like accedentaly Ctrl-V on an untrusted site which caputes typed/pasted texts.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.