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?
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
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.
@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?
One of the better reasons to use Gemini, IMHO.
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.
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.
@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.
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
@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.
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.
@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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.