Hacker News Reader

Comment by gcb0 | Hacker News Reader

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.

View on HN

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.

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.

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

Certificates can also be marked as non-exportable.

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

Reply on news.ycombinator.com