Cutting the Gordian Knot of Web Identity
codinghorror.com
codinghorror.com
1) Password management, which is a solved problem by geeks and normals alike. Geeks use password managers. Normals use three passwords.
2) Single sign-on, which is less medicine and more vitamin as far as things go.
3) Net-wide identity. HERE BE DRAGONS.
As soon as you start doing the most trivial possible quanta of work to resolve the OMG DRAGONS, you start compromising the system's utility for password management and sign-on.
You'll need, minimally, new UI for "What information about yourself should we share with $NEW_SITE?" and for switching between users/profiles. This will happen in ways your users don't really understand.
Among the many OMG DRAGONS:
1) Microsoft, Mozilla, and Google can get into a corner and say "Heya, federated identity would be the awesome!" all they want, but there are laws in the US, Japan, Europe, and points beyond which don't make "It is an open standard!" int a compliance safe harbor.
2) You know that whole Google+ thing about real names and people having multiple identities which don't necessarily intersect with each other? Yeah, um, that.
3) Speaking of which, how about the other intractably hard problems for pre-filled biographical information like e.g. human names? They're, ahem, a wee bit tricky!
I know the obvious answer: for the advertising and marketing leverage. I'll do my own hand-wave here and say that this is specious, that there's a sufficiently rich predictive dataset based on other extant characteristics (browser type, IP location, on-site behavior) to do an adequate job of targeting ads to my instance of AdBlock+.
A large part of the reason I don't subscribe to sites such as The New York Times is ... I feel really uncomfortable having my list of reading preferences on the news site available. That's discoverable in all sorts of ways (legal or otherwise), and I have to trust in the Times, its staff, temps, contractors, third-party business relationships, vendors, ISPs, systems disposal methods, etc., etc.... Multiplied by every site on which "I" have an account. Um. Thanks but no.
There's the issue of payment. Bitcoin is only the latest iteration of a digital cash. Many banks now offer one-time payment tokens. There's no technical reason (though arguable usability reasons) for me to have to provide a shared secret (my account number and verification code) with every online (or offline) financial transaction. This system is proving increasingly fragile, and both online and offline systems have and will be compromised. Cash risks only the current value held. Credit/debit risks a future stream of compromised payments.
I'm moderately fine with the old-school world of pseudonymous passwords, especially with fallbacks of cypherpunks/cypherpunks, or cowbodyneil/cowboyneil (or BugMeNot) on sites. If nothing else, I'm sending a very clear signal that I don't want my data mined and I don't trust YOUR systems for guarding against this so I'm invoking my own.
There's still the closing problem of delivery. This can be managed by various means, including selective disclosure to the shipper only.
In the real world, we engage in complex transactions based on very limited identity and information disclosure. The person who makes my pencil (or ThinkPad) has no idea who I am or where I live, let alone much information about the other entities responsible for the production of the product.
The technologists here know that building a modular system with limited information disclosure based on what's needed to accomplish a given transaction, presented at the interface between operations, leads to a simpler, more robust, and ultimately better system. Why are we trying to design an online commerce system that's at such odds to these principles (see "ads/marketing comments above)?
However, here's an interesting authentication solution I've been reading about lately[1] proposed by an actual security researcher. That blog post links to his peer-reviewed paper and to a talk that he gave.
The idea is basically to have a specific identity manager device he calls a "pico", with a little camera on it. Web sites can display a QR-code or something with its public key in it, you point the pico at it, and the pico authenticates with the site on its own. His proposal also includes weird "pico siblings" and stuff like that, which seems unfeasible to me, but some version of it as a mobile app might be interesting.
[1] http://www.lightbluetouchpaper.org/2011/03/27/pico-no-more-p...
Still, they are a nightmare. What if facebook decides to ban your domain? What if user's account gets hacked?
What if we changed the rules of the game a bit: Take your cookies and browser settings with you in a USB key. Websites know you by the session id stored in your browser-wallet. They don't even need to know your name or your password. You can use your friend's computer and fool around, without having to delete recent history and cache afterwards.
Or instead, store browser settings in the cloud, or in a secure P2P network. Login to the browser, not websites. Google sync does that partly, and it's convenient. No need to transfer bookmarks, settings and passwords when you get a new computer. Maybe that's where we are headed.
He doesn't mention whether or not you need a password to connect your new phone to your cloud identity wallet...
If the goal is no more passwords, what is the handshake mechanism to move my Firefox data to Opera?
I wonder if, at least in some cases, we could somehow get rid of identity requirement altogether: given a site that currently requires user accounts, change its mode of operation so that identity either doesn't matter at all or doesn't matter as much (the site is useful for anonymous users)
Assuming I give them the public key rather than relying on some sort of CA system, we've also removed the problems inherent to authenticating through a third party.
As far as I can tell, the only problem with this approach is poor browser support. To my knowledge, the only public key systems that have wide browser support are tied up with certificate authorities and other stuff for actually verifying a real identity, which is a separate (and much more difficult) problem. It seems to me that if we just had something that worked like OpenSSH public keys that worked in a web browser, we'd at least have solved the problem of coming up with secure passwords for every site.
Same idea: A browser (or extension) that knows how to sign up, and log in. Sign up would fill in the form from my choice of profiles (personal, work, fake). Log in would automatically use the saved credentials, and allow me to switch accounts from within the browser. Sync it to the cloud, or let me export/import it to another browser or device.
Edit: HN discussion of that post: https://news.ycombinator.com/item?id=2128966
edit: never mind. It's back.