The problem of web identity isn’t caused by passwords, it’s addressed by passwords. Eliminating passwords only obfuscates the problem!
Remember that cutting the Gordian knot was a bad thing. It symbolized a regression to brute force and violence. The knot puzzle represented intellectualism over barbarism. By cutting the knot with a sword, Alexander the Great propounded brute force as the solution, when in reality that was the problem.
The brute force approach of addressing Web Identity by re-engineering browsers/html/protocols to natively support automatic password handling is a fool’s errand at this stage in the development of the Internet.
Thankfully what’s great about the Internet is that it solves its own problems through a bottom up natural selection process based on pure useage.
Much like every other web usability paradigm that came before it, proper and effective third party login credentialing will become second nature to the web development platform and ultimately a norm of internet usability.
Until an ubiquitous hardware solution changes the game, users will always need to remember (or use tools to remember) the passwords to their major account providers, but eventually any website and/or service that requires identity to function properly will not have to annoy the user by requiring their own identity forms/procedures.
Really, the only way to get around this is through some common sense, especially on the web providers side.
#1 IF THE SITE DOES NOT NEED A FRIGGIN USERNAME/PASSWORD THE DON’T REQUIRE ONE!
#2 I like the idea of a sharable password among sites even though the security of such schemes is questionable however; this could be accomplished with the combination of some sort of dual key so that you enter a simple password like say my dogs name and then the password provider site combines it in some strange way to create the master password that is really used. This should protect from script kiddies but not from a serious hack attack.
Maybe recording the radio attenuation of latest solar flare xored and bit shifted and then ones complimented…
You see what I mean…
Nothing is really secure unless it is not attached to the net. Even then it can be physically stolen.
Interesting. However there are still passwords involved, albeit hidden from user.
I think that OpenID and widely accepted providers like Google are a way to go. Lots of sites (no need to name, I suppose) already support these technologies and devices (Android Apps) work with them too.
You get added benefit of such features as multi step (hardware token) authentication and one-time passwords. Perfect!
There is a system that already works much this way, with the following advantages:
No need to trust a cloud.
Browsers already support it.
It’s easy to program on the server side.
It’s extremely secure, with no known attacks.
That’s right: it’s standard public-key encryption using a client certificate.
Of course, the big problem is that “pki is too complicated for average users”. But I think this can be mitigated in two ways:
Introduce it slowly, but in mandatory ways, in domains that (a) people need to use, even if means learning something new, and (b) really need more security than current systems can provide. The perfect case is banking. Banks should require pki access to their websites - they can even market it as a competitive advantage, since it’s that much more secure than passwords. People will complain, but eventually would learn how to use it, and then the rest of the internet could jump on board.
You can provide key management browser plugins that store your key in the cloud for people who don’t want the hassle of managing their own keys. Less secure, but the secure option is still available for those who want and value it.
A little late to this party, but thought you might be interested in work I’m doing open-source at Google: The Belay Project ( https://sites.google.com/site/belayresearchproject/ ). I admit the write-ups are currently thin, and presentation poor, (I’m workin’ on it…) but the current open-source code base demonstrates a working system that meets the objectives Jeff is after.
In Belay, rather than a browser extension supplying generated credentials to the web site, the web site supplies credentials to the user’s chosen “store” of such credentials. We’ve worked out the gritty details to make this work with no browser extensions, to allow total freedom for the user in picking where to store these things, and (perhaps most importantly) all the UI so that user experience is extremely smooth. What results is a system with no required passwords or account names (or cookies either!), and both the account creation flow and the login flow don’t need to have intermediate approval pages.
Development is being done all in the open, though I admit it is relatively early-days for the project. The features described above just came up and running in the last month. I expect to have a much more friendly version hosted for developers to experiment with soon. In the mean time, If you’re in the SF Bay Area I’m happy to demo the system. I’ll also be at IIW 13 in October, if you’ll be there.
Sadly Microsoft dropped CardSpace this year, seemingly due to “Not solving an immediate perceived problem” and being “Not drop-dead simple to use” according to Mike Jones. http://self-issued.info/?p=458
We had Apache’s httpasswd to talk to browsers on http level for that purpose. Somehow we didn’t pursue this way. Anyway I use Lastpass and don’t care about passwords anymore.
Jeff:
Seriously Password maker (http://passwordmaker.org/) does EXACTLY what you are asking for already WITHOUT the need to trust some third party site (such as lastpass which has already had 1 attempted break-in !)
And while its not a “standard”, its implementation is so straight forward they have clients for almost any browser/device you are using right now.
Like everybody else has already said, what you’ve described is pretty much how PKI / private-cert login works already. If you take out the part about needing a trusted issuer – that is, if you don’t need a 3rd party to verify that this cert belongs to this user – then it becomes free, and, like you asked for, every major browser (plus every major HTTPS connection provider in every major programming language, let’s not forget!) already supports it. Want to change the world? Make a 2-click certificate generator for all the major platforms (simple wrapper around command-line openssl), tell people how to import them into the browser, then add support for cert-based login to SE.
What cloud service could be relied upon to be available enough to make this work? No amount of downtime would acceptable. A local solution, replicated by a cloud service perhaps (e.g. something like a 1Password/DropBox combo), has to be the underpinning so that credentials are always available, and across all of a person’s machines.
Thank you for the awesome blog. I first read one of your posts and I thought since you are too busy building stackoverflow I thought I should go and read all the rest of your blog. And boy what a ride it was.bas of today I finished every post you made. And I learned more in here than I did in my whole education. Keep posting awesome stuff. I am a regular user of stackoverflow and after getting my over 100 consecutive days badge I finally figured out what is the next best thing to answering question in stackoverflow. It is building my own website and asking questions when I need help. The only website where u get real answers in less than 5 minute. So kudos I will be waiting for your next post.
If my bank wanted me to sing using OpenID or similar, I’d move to another bank, but if it’s a social networking site, I think it may be fine.
As I understand the problem, it’s not the security that is the of the most concern, it’s about usability. I think that if you don’t try to solve two only slightly related problems at once, you may do better. A bank or an on-line shop, or an MMO game of certain type will enormously benefit from having your actual info. They also have almost no motivation to share it with other parties. Having a common body that would issue identification certificates in real world, that would hold valid on the internet is a good idea I think.
On the other hand I don’t see why would I want to give this information to a social networking site. More yet, if the site demanded it of me, I wouldn’t use it, or if I totally had to (unfortunately, that’s part of my job), I’d forge it.
As the result, I’m not quite sure both problems may be addressed in the same way. I’d rather they aren’t.
Basically what you just outlined, is Facebook logging in, once you’ve already logged in once. A decently designed website would know not to ask for authorization again but just retrieve the correct data based on your previous login. Technically, you only have to make sure you’re logged in to Facebook once on each of your devices. Once you’ve created an account and authorized it to use your Facebook credentials, you don’t need to repeat that process. Next time you log in you just click “log in” and the work is done for you
That a website could correlate our successful visits if we wish to, in order to present us the settings / data we saved
That two different web sites may not correlate our accounts (well, there is IP… but there are proxies)
That this identity could be shared freely between different devices, but be tied to a single individual
I don’t really think that we need a passport or passphrase for this. And as much as people tout it, I don’t think that PGP is what we want either: PGP gives only a handful identities.
I think the one person to solve this problem will be hailed for generations… and those who fail will be forgotten (at best).
IMO, there should be a trusted third party, such as Google, which manages everyone’s web identity.
The key is to back this up with legislation. Wanna hack everyone’s web identity by hacking Google? First of all, good luck. Second, if you do manage to do it, you will be punished. By law.
So, if we back up a SINGLE third party with legislation (IMO, it should be Google), we have solved the problem. If Google got hacked, the culprit would have to endure severe penalties, and everyone ELSE would simply have to recreate their web identity. Recovery of web identities and data is hard to trust after the hack occurs. Recreation is essentially a non-ordeal. However, all saved data from a previous identity would be lost. Hence the reason the culprit would have to endure a lot of jail time.
