

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

Logging into one of my unix hosts, I merely enter<p>$ hostname.org.com<p>And I'm in.  I'm in without specifying credentials every .. single .. time .. because I use SSH passphrase keys, with a passphrase.<p>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.<p>...<p>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?<p>That is, a user would ..<p>- create a key
- push it to the web server
- when you login, web server looks for that key and ... you're in.<p>This - to me - would seem to be a lot easier than what we do now.<p>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.<p>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.<p>But we don't do this.  The reason is probably simple, but I'm just not seeing why.
======
dchest
Technically, we do this: SSL client certificates. Nobody uses them, though.

[http://pilif.github.com/2008/05/why-is-nobody-using-ssl-
clie...](http://pilif.github.com/2008/05/why-is-nobody-using-ssl-client-
certificates/)

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

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

------
toddkaufmann
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.

~~~
bdunbar
> 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.

------
sp332
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.

~~~
bdunbar
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.

~~~
curiouscats
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...](http://www.wired.com/wiredenterprise/2013/01/google-
password/all/)

~~~
wmf
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.

------
ronreiter
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.

------
jimktrains2
<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.

------
ibudiallo
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

~~~
bdunbar
> 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.

------
sumguysr
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.

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

~~~
bdunbar
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.

------
meffie
see WebAuth, CoSign

