Comment by pilif | Hacker News Reader

Comment by pilif | Hacker News Reader

I'm the author of this post which I have written in 2008. Since then my views have changed a bit: for one, the added security is debatable as the client cert is easily accessible to malware and thus could easily be stolen.

The other thing is that renegotiation is somewhat broken since that related security flaw in 2010ish, so you can't have parts of a site accessible without client certs and other parts requiring a cert.

This has been fixed since, but I don't know how well it's supported by clients.

Finally, compared to 2008, we're using many more devices for accessing various web applications now. Having the client cert bound to one browser on one machine is annoying and synchronizing it truly securely is probably impossible.

I do stand by the horrendous UI though. Even if the other issues weren't there, the UI certainly kills client certificates for normal users.

Then again, crypto UI is hard and I'm afraid the incentive for redesigning this is pretty much zero because nobody is using it to begin with and because it's flawed anyways.

The U.S. government is a very large user of PKI.

One is issued an identification card which is really a smart card ("common access card"[0]) with certificates on it and that is used for authentication.

PKI works but "it's too {hard|much trouble}" is a frequent excuse.

[0]: https://en.wikipedia.org/wiki/Common_Access_Card

the malware point is moot.

malware can steals passwords saved, which are optionally saved encrypted. the cert at least in the one browser i checked is always encrypted.

and even then, if you have malware in your box, any and all security measures are worthless at this point.

decent Renegotiation and mobile client support will come if people using that on the desktop request the feature. it's like that for everything for a while now.

Managing the devices and revokation is also trivial. most sites does that very easily with API keys and cookies (e.g. google 2step auth, you can control which cookies are still valids for the 'remember this device' feature). the same logic could be used for client certs.

Certificates can also be marked as non-exportable.

Unless there's some trusted hardware involved, I doubt that effectively prevents malware from getting them.

And managing multiple devices is actually a security boon. If your auth creds get stolen you'll know what specific device was compromised and can revoke the one vs a reset of all creds.

Also agree that malware is moot (it can steal auth tokens live as they're submitted, so even physical tokens requiring 2-factor pins get compromised).

The problem is browsers haven't been proactive in making the technology user friendly, so websites don't adopt it, so browsers don't make the technology user friendly. A couple large icons and good design decisions would make it as easy as logging into your screen saver.

That's a reason I use different sets of SSH keys from different hosts, or at least different classes of hosts.

It's rather troubling to find that many SSH management tools (including Puppet/Chef recipes) deal poorly with multiple keys per user.

It's more than icons and design.

Users. Do. Not. Understand. Certificates.

If the word "certificate" or "public key" or "private key" appears anywhere in the process, it's a non-starter. If they have to select a certificate from a list, look at a "fingerprint", or deal with any other jargon like "x509" or "certificate authority" or anything along those lines, it's dead in the water.

I agree with your malware point. If your system is compromised, and attackers are past the 'airtight hatchway', then you're doomed anyway.

What I meant about malware is that client certificates can't provide additional security over passwords because malware can easily steal both.

So it's only hassle and no advantage, hence, useless

Other than passwords, client certs cannot be guessed or generated with wordlists, they can not be used to authenticate to other sites even if stolen, and they cannot be forgotten (at least I tend to forget passwords for rarely used sites way more often than I lose data through HW failure).

So I'd say there are some advantages over passwords. And most of the functionality is already there, the only thing missing is a browser function to generate a keypair for a domain and send the public key, without much user interaction.

That's already a thing, if I understand what you're asking - see the <keygen> tag.

Client certs can't be phished

The can be revealed by other means (trojan/virus on the client). But yes, the anti-phishing aspect is a good one.

password can fails all those plus phishing.

Not really. you could use a storage medium that is remote and load it in memory only, if the usage justified.... not case, for reasons you outlined eloquently on the article.

Also, the client cert, as with private keys, allows you to memorize ONLY ONE password (make it a passphrase, please) instead of a bazillion (or, gasp, reusing).

So, no, it's not an extra hassle. it's a solution for the real hassle of passwords in websites. if it was used.

Isn't the point of client certs that the private key should never leave the machine? I.e. when you want to get access from a Smartphone you just initiate a new certification process, some admin ticks off a new public key and you're set? For consumer faced apps I could see some initial authentication process where for every new public key the user gets an E-Mail in order to activate it. Using it this way I think there is also no reason to use the browser UI for importing / exporting certificates, at least not for the users themselves. Still, the question remains why no-one is using it.

This is why: I know one company & service which did. But after a year or two they gave up. It just complicated things, overloaded helpdesk and made customers angry. They used client certificates to count 'workstation licenses' for a web app.

Well, using it for licensing is of course harder to argue for than increasing the user's security. May I ask what were the specific problems in your scenario? I'm guessing users with multiple browsers? That's another reason why I hate Windows not having a central MS provided keyring. If MS had pushed for it soon after the POSIX community and Apple, passwordless authentification might be already a standard nowadays.

Persona synchronizes client private keys. Its not SSL Client certs but its not all that bad.

What I'd like is the same thing but be the owner of the private keys, stored on my external, physical token.

This works with SSL client certs, yes, but its a pita, and there is no trust from the client by the server if its never been seen before.

GnuPG actually works like that properly (with the MonkeySphere project for the web stuff), but its not used anywhere..

The UX on iPhone isn't so bad if you are using .mobileconfig's and there aren't conflicting certificates. I'm actually starting to open source some of my work in this space.

OSX will still prompt for the certificate even if there is only one matching, but again it isn't too bad.

Though in iOS 7 / Mavericks I'll probably switch to using Keberos, which will be seamlessly integrated into the Objective-C's networking APIs.

Adding to your third point I am pretty sure there is still awful mobile browser support for client certs which is a dealbreaker just about every site out there these days

Reply on news.ycombinator.com