31–40 of 160 posts
Today, it's much harder to support every browser and OS.
The whole DOD is using it, but they're on crypto smart cards, so many folks don't realize that's what they're doing. Email, single sign on, web site auth, etc. Works great!
Good luck to them if they want to install a different browser (non-IE) or do anything non-standard... if they even are allowed to do so.
Try having two client certificates and seeing the browser UX for selecting which one to present to which site. You'll see why they aren't used. Client certificates should be much more popular in backend applications, where they're straightforward to use, flexible, and fairly trustworthy. But they're not a good end-user technology.
I agree that for machine to machine communication client certificates work well. Especially if you implement your own CA so you don't worry about the public infrastructure.
I use it for StartSSL. It allows me to use SSL client cert auth for their OpenID instance.[0] I use it to log into StackOverflow and a few prominent sites. I like the idea of my cert provider being a trusted party for auth for other sites. However, trusting anyone other than himself in this post-PRISM era is probably a mistake. [0] http://www.startssl.com/?app=14
Yes, it's true. Not sure why it's news, other than it's a new article? This has been an abomination since .... the functionality was added. It's hard even for geeks to deal with it - it makes 0 sense for non-techies to even contemplate dealing with it. Relatedly, browser UI for dealing with cookies has been abysmal since day 1 as well. Instead of making cookie information easily visisble and manageable, browser maker…
Yes, it's true. Not sure why it's news, other than it's a new article? This has been an abomination since .... the functionality was added. It's hard even for geeks to deal with it - it makes 0 sense for non-techies to even contemplate dealing with it. Relatedly, browser UI for dealing with cookies has been abysmal since day 1 as well. Instead of making cookie information easily visisble and manageable, browser maker…
> Instead of making cookie information easily visisble and manageable How do /you/ suggest making base64 encoded blobs of context-less ID numbers understandable to the average browser user, assuming that they could be persuaded to care in the first place? Even as a geek who knows where to look, I look at the cookies from most sites and have no idea what they mean :P
We have 'home' and 'reload' and 'back' and 'forward' buttons. Actually, no, my safari doesn't even have a 'home' right now, but a 'share'. Why not a 'cookie' button.
Again, doesn't particularly matter whether you can decipher base64-encoded stuff or not - the average person has no clear way to even understand the number and type of cookie data being tracked, nor an easy way to block/unblock without wading through multiple levels of menus which take them away from the site they're on.
Doing this on smartphones would present a challenge, but is not impossible. Doing this is desktop browsers shouldn't be all that hard. We see the data in firebug - parsing out request headers and showing the cookie data (with block/delete/allow options) in a sidebar panel would not be hard. But it won't have any real impact unless it's something built-in to multiple browsers and we have an education period.
The late 90's was full of "ban cookies! reject cookies! they're evil!" hype, then we all forgot about it for a while, endured the rise of doubleclick and the like, and got legal solutions vs good UI solutions. :/
EDIT: I hit save too quick. I don't think this will ever happen - at least 2 major browser makers have a vested interest in keeping the ad-based tracking economy moving along - any built-in browser functionality which would interfere with that will never fly. I'm talking about Google and Firefox (which relies a lot on Google's wellbeing re: ad revenue). I imagine MS is in a similar boat, but maybe not to the same degree as Google. I can't speaker for Apple's potential for this, but given the webkit tie between chrome and safari, it's probably unlikely as well.
Earlier quoted context omitted.
The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.
Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.
1- simpler implementation — one that is easier for users to understand, and includes client certs by default
2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years
SSL was originally meant to serve two purposes:
1- encrypt communication
2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is
Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com.
I think that kind of authentication has a real place on the modern Internet.
edit: formatting
Earlier quoted context omitted.
The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.
Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.
Now with PRISM and total global surveillance becoming a sad reality, we could certainly do with more decentralized approaches and (ideally) overcoming the "authority" paradigm (but this will likely remain a dream).
Earlier quoted context omitted.
I would love to hear more about this. I've been looking for a good sso solution that uses crypto cards.
My understanding is that the private key is on a CAC card[1,2], which is issued to all DoD employees and contractors who need access to DoD resources. Readers are usually built into the keyboard, and I'm guessing that there's something similar to ssh-agent running to maintain the key until you're AFK. -- [1] http://en.wikipedia.org/wiki/Common_Access_Card [2] http://www.cac.mil/