Ask HN: Why aren't we using SSH passphrase keys for website logins? | Hacker News Reader

Ask HN: Why aren't we using SSH passphrase keys for website logins?

10 pointsbdunbar21 comments

Logging into one of my unix hosts, I merely enter

$ hostname.org.com

And I'm in. I'm in without specifying credentials every .. single .. time .. because I use SSH passphrase keys, with a passphrase.

I can do that because I took the trouble to setup my ssh key and copy it to my server's $HOME/.ssh directory, performed a little magic on it.

...

I had this thought the other day, when I was logging into gmail and work-help-desk and work's erp platform and the EDI tool .. all of it web based and all of it requiring me to specify userid/password ... why don't we do SSH passphrase keys for websites?

That is, a user would ..

- create a key - push it to the web server - when you login, web server looks for that key and ... you're in.

This - to me - would seem to be a lot easier than what we do now.

Inside a company we require a lot of userid/password keystrokes, one per application. Even with SSO (via LDAP or whatever) we still require these keystrokes.

In the wild internet to either remember userid/passwords, or store them in your browser, or use an add-on for that purpose. We're still using userid/password and that sucks, when you could simply point the login at your key and bang out a passphrase.

But we don't do this. The reason is probably simple, but I'm just not seeing why.

Technically, we do this: SSL client certificates. Nobody uses them, though.

http://pilif.github.com/2008/05/why-is-nobody-using-ssl-clie...

I have rolled out SSL client certificates to a client for authenticating remote users to a web-app so they could work-from-home.

StartSSL also uses them for authentication. These cases are very rare, though.

Thank you! I vaguely recall reading about these, a long time ago.

What you mean is not "passphrase keys" but "public/private keypairs", and it sounds like you are using an agent as proxy, so you only have to authenticate locally once.

This isn't an answer, but: password managers like LastPass can do this for the web. I let it generate secure passwords like "e^9u21$Fb%mJv"--in fact I don't know most of my passwords, it logs me in automatically, I just authenticate once with a passphrase. Highly recommended (integration with most browsers, other security features, see the website); definitely worth a look for the interface considerations alone.

The answer: it's probably too hard to get there from here now. Too many changes to UI's, re-education of users, and really they don't care if you have to type in a password every time or click an extra page.

Look at the popularity of decentralized private/public key trading with (e.g.) PGP. NOT. Sure, the paranoid elite have learned how to use the keyservers and mixmaster remailers, but there needs to be a killer UI that's simple enough (or maybe just smarter than the user) before people.. will... post to facebooks with it?

Client SSL certificates were supposed to be a thing once back in the 90's--everyone would have one, it would identify you to your bank uniquely, and everyone would be secure. I'm pretty sure the protocol still allows for it, but I think I only saw one website use/require it, and not sure it was this century.

Big ups! LOVE LastPass.

> Look at the popularity of decentralized private/public key trading with (e.g.) PGP. NOT.

Haw. At a previous employer, in 2001, we started a project to deploy PGP to everyone. The idea was we could encrypt our work, email, send files to customers ... the boss was _keen_ on the idea. Our customers liked the idea, some of them.

We were acquired and our new owners were lukewarm to hostile about the idea and it was dropped.

> but there needs to be a killer UI that's simple enough (or maybe just smarter than the user) before people.. will... post to facebooks with it?

I think that's the key, right there. Make it simple, easier to use than userid/password.

You would have to transport the key to each computer you want to log in from. You couldn't just sit down at a friend's laptop and log in to your account on a website.

Ah. Shoot - hadn't thought of that edge case.

Keeping the private key on a third party host would negate the whole point of _having_ a private key. I suppose one could dodge this by encrypting the encryption, or have it stored 3rd party and then download it where you need ...

But that's two sides of the same coin. And making it way more complicated than userid/password.

Which right there is enough to make the entire deal unworkable. Dang.

Thanks.

Couldn't you have the keys on a device (USB stick, smart phone, dick tracy/apple watch ...) that went with you everywhere? Seems like some version of user verification that relies on something like this is likely in the fairly near future. Google is looking at the idea of using hardware rather than username/password http://www.wired.com/wiredenterprise/2013/01/google-password...

Sure, just modify every browser to support hardware tokens out of the box. Being logged in simultaneously from multiple devices (like a computer and phone) is also problematic with hardware key storage.

> Couldn't you have the keys on a device

An issue with those is that's just one more thing to keep track of. And, hardware costs money, and that's just one more thing to keep any solution from being adopted.

Actually, this is a good point, but only as a measure for increased cookie security. Today, HTTP cookies are very vulnerable, and this method can actually solve session hijacking if public/private cryptography will be applied on every request.

https://developer.mozilla.org/en-US/docs/HTML/Element/keygen

> The HTML keygen element exists to facilitate generation of key material, and submission of the public key as part of an HTML form. This mechanism is designed for use with Web-based certificate management systems. It is expected that the keygen element will be used in an HTML form along with other information needed to construct a certificate request, and that the result of the process will be a signed certificate.

If I understand this correctly, you mean cookies right? Isn't that what they do ? If you have cookies enabled, for most websites you don't need to reenter your credentials .

If that's not what you meant please clarify

> If that's not what you meant please clarify

I didn't mean cookies.

I meant the process of -getting- a cookie. I supply userid/password to the website, get a cookie.

Granted, once I have the cookie I'm good.

But ... what I feel I _should_ be able to do is supply a key to the web server, same as I supply a key to my unix hosts to login.

It has bothered me for a long time that browsers have no interface showing what websites one is logged in to, and allowing one to log out of them.

For 99% of the Internet users this will be outside of their knowledge scope.

I think if people can learn to swipe a credit card then they could learn to insert their smart card to log in to the Internet. As long as somebody other than the user pays for all the required infrastructure.

You have a good point.

I don't think it needs to be this way. A lot of tasks that we ask users to perform are out of their knowledge scope. We gussy them up with dialog boxes like

'It looks like you've lost your network connection, would you like me to repair that'

And then Windows goes out and does an down/up on the network card, reapplies for an IP and I don't know what all.

To the user, the computer pauses for a minute, the computer notifies 'You're up, back to pr)n surfing' and away they go.

see WebAuth, CoSign

Reply on news.ycombinator.com