141–150 of 160 posts
The reason I would like a client certificate solution that worked (even if it was a malware target) is that I could reject all web traffic to my applications if they came in without a cert. It would decrease my public footprint dramatically. I don't mind approving a user once per device. We've got to set them up anyway.
Use client certs then? Why do you feel current solutions don't work?
Earlier quoted context omitted.
This is an unrelated security measure, but you are correct. And if you pull the card out, you can't access anything anymore that requires it (and on a Windows domain that DOESNT lock / terminate the session, you'll be able to access things until your kerberos ticket expires or you need to get to something you don't have a ticket for).
I once volunteered at a hospital where they made use of a smart card security system - among other things, it would log you out if you removed your card from the reader. This closed all the programs you were running - and logging back in was a slow process. Needless to say, the smart cards stayed in the users' PCs even when they weren't at their desks.
We use client-side PKI and certs, not just with employees, but with customers, at OpenDNS. Works well, is a very strong added factor, and is easy to manage and deploy these days.
Earlier quoted context omitted.
Speaking of backend applications, Puppet uses client certificates to authenticate machines that are being administrated by a Puppet server. I used to work on that code - none of us would have ever called it "straightforward". The library support for client certs is underdeveloped and poorly documented - probably because so few people are using client certs in production.
I feel like I've written a fair bit of client certificate code in Ruby and haven't had much of a problem. Where did you run into problems?
Earlier quoted context omitted.
You're right, it's a ridiculously large organizational overhead. Not to mention the CA's become single-point-of-compromise for the whole PKI. Even after 10 years or so of the CAC, the DoD process is still not pain-free. They've finally moved to OCSP instead of CRLs, which helps (the CRL is so large now that it will bluescreen Windows on import to the registry, haha) some of the pain. Even the DoD doesn't roll it's ow…
the CA's become single-point-of-compromise for the whole PKI. It's a bit more nuanced than that. A compromised CA can issue new certs which can spoof old one's identity, but it can't be used to create certs which will read traffic from an existing host. The big risk is that someone is subject to a MITM attack, doesn't clue in on the certificate change (their client should note this), and accepts the new key. Signed /…
Earlier quoted context omitted.
I don't work for the DoD, but you have the process right as far as I've seen. Don't forget that they seem to want a new set of fingerprints every time you go in.
Yeah, it does suck to be CTR, I'll admit. Especially if you need separate CAC credentials for things like base access.
Earlier quoted context omitted.
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…
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 friend…
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.
Earlier quoted context omitted.
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…