Cutting the Gordian Knot of Web Identity

September 6, 2011

Perhaps you've seen this recent XKCD about password choice?

To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.

It prompted a spirited debate – even on our very own Security Stack Exchange – about the merits of the argument presented there. Now, to be clear, I'm completely on Randall's side here; I'm all for passphrases over passwords, and I have been for years.

But this is merely one symptom of a much larger disease: identity on the internet. Every time you touch a website that actually cares who the heck you are – and this is an increasingly large list of sites as the web matures – you have to, sigh, "log in". And logging in inevitably requires you to create a username and a password. Over and over and over and over. And, oh by the way, you'll be logging in again each and every time on every browser and every computer and every device you own. It's a great system. And by "great" I mean fracking terrible.

This isn't just tedious busywork for us, the poor web users, it's also downright dangerous as I explained in The Dirty Truth About Web Passwords. It's a near-impossible problem, an intractable Gordian Knot. So I'm going to answer one comic with another.

Watchmen-gordian-knot

The problem is not choosing better passwords for the dozens or hundreds of web sites we have to log in. The problem is passwords.

Thus, the only real cure to the disease of identity on the web is to get rid of passwords altogether.

Yes, you read that correctly. But "Jeff", you might say, "how can we possibly log in to websites without our beloved, mile-long list of site-specific usernames and passwords?" I'm so glad you asked! Try to make time in your busy schedule of account and password creation to read a few more paragraphs into this post and I'll attempt to explain my crazy scheme.

We could use our internet driver's license and log in to a particular website using our existing Google, Facebook, Twitter, or OpenID credentials. This works, but it assumes a lot; is the website enlightened enough to accept third party logins, or is there a political agenda (or delusions of grandeur) preventing them from recognizing any form of identity other than their own? To be fair, accepting third party identity is hard and undeniably adds complexity. There are a million ways to get it wrong, and only a handful of sites that get it right. I like to think Stack Exchange is one of the websites that gets this right, but I'll fully acknowledge that it is challenging to get there. Unfortunately, the path of least resistance for web identity leads inexorably to one sad, depressing, dysfunctional place:

Username-password-input

Yep. Get used to it. Username. Password. For every single website you'll ever visit. On every single device you'll ever own. Forever. Until the end of time. Oh God.

Lately I've begun to hope there might be a viable solution, even outside the third-party logins I've championed for the last 3 years. A way of absolving users of username and password selection. Like Alexander's solution to the Gordian Knot, it might be a bit scary in its … absolutism. But anything has to be better than the unspeakable terror of a million logins on a million different websites on a million different devices. Right? Right?

(Warning, Extreme Hand Waviness Ahead: while I do honestly believe the techniques described below would work, I am glossing over many of the technical implementation details. This is absolutely not intended to be a spec but an "I Have a Dream" outline. Feel free to help me clarify and expand on the necessary details by blogging a more technical plan for this in any form you like.)

Imagine, if you will, visiting a new website and deciding you'd like to create an account there. You click the "Create New Account" link and then …

  • The website presents a secure account creation page decorated with specific meta tags that indicate this page supports automated account creation with a standard(ish) set of user info HTML form fields.
  • The browser, seeing these meta tags in the page, does not present the page to the user but retrieves the user's standard information fields like name, email address, etcetera from some form of secure https cloud storage, and readies them. The browser will also automatically select a completely random, cryptographically secure password for the new account.
  • The browser must, unfortunately, prompt the user with a confirm dialog containing a CAPTCHA at this point to ensure that the signup process isn't being scripted in any way, and that a real human being actually wants to create an account on this website. While we're there, we might as well confirm the identity data we're about to send to the website (though hopefully the defaults should suffice). Once confirmed, the user credentials and password will be sent to the site and stored securely in the cloud.
  • The website redirects the newly created account to an appropriate page.

There may be some more information that the browser (or the site) needs to ask the user for in there somewhere. But account creation is a one-time event, and in the typical case where you're signing up for some simple website, your preferred defaults should suffice. Caveats aside, look what we have wrought: you clicked "Create New Account", completed a single captcha and clicked OK – now you're logged in to your brand new account on any website.

Once you have an account, it's even simpler. Imagine clicking the "Sign In" link, and then …

  • The website presents a secure login page decorated with specific meta tags that indicate this page supports automated login with a standard set of username and password HTML form fields.
  • The browser, seeing these meta tags in the page, does not present the page to the user but retrieves the user's credentials from some form of secure https cloud storage, and sends them to the site.
  • The site receives the credentials via https, validates them, and returns a valid login cookie to the browser.
  • The browser redirects the now logged-in user to the page they originally wanted to see as a logged in user.

From the perspective of this weary citizen of the web, at least, a miracle just happened. You clicked "Sign In", and you're immediately signed in without having to look at a single stinking username and password field!

Seems like magic, yes? Gotta be a catch, yes? Well, there is. Two catches, to be precise.

  1. Web browsers will have to be rewritten to understand basic identity protocols. I suppose it could be a browser plugin as well, but I'd rest a lot easier knowing basic identity protocols are officially "baked in" to the browser and supported by the Powers That Be, perhaps even as accepted W3C standards. And yes, you will need to log in to your browser at a minimum.
  2. You have to trust "The Cloud" at least a little. There has to be some trusted, secure location on the internet for all your usernames, passwords, and basic identity information to reside. Otherwise this scheme can't possibly work, because how would you log in from your (insert favorite device name here) if it has no access to the secret, hidden list of account information and automagically generated secure passwords created on your behalf?

Identity is fundamental to the modern internet; more and more websites need to know something about who you are to work. The current status quo of thousands of websites with thousands of differing ideas about identity and passwords and account information is beyond broken. We want – no, we demand – that the browser understand and standardize identity the same way it does HTML and CSS. Maybe it's crazy, but I dream of the day when I never need to see another password field in my browser ever again.

I hope you can too.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

Posted by Jeff Atwood
126 Comments

Hi Jeff,

Do you know what foobar stands for?

This is a classic foobar!

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.

Regards,

Mac

John McPherson on September 12, 2011 2:24 PM

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!

More clients just need to start supporting this.

Josef Sábl on September 13, 2011 3:06 AM

Are you describing LastPass? because, the way I see your explanation, is like what I already did (granted, this is not built in the browser).

Right now, I can do every login using lasspass. On blackberry, android, even on every browser I have.

One password to rule them all, with bonus: secured cross-platform notes!


From a happy user.

Arief Purwanto on September 13, 2011 5:13 PM

Ha ha.. It is the shortcut to use the "document viewer" as application base. (A)PatChi solutions.

Just an (root cause analysis) RCA view as monoact.

Why I have to use HTML for an application?

PROGRAMMER: Rendering is already available inside HTML engine.
.
.
.
END USER: I dont trust the binary junk. Send me plain text and I shall process it.!

HACKER: Oh.. you dont trust!. (in my wall) Customer is always right! and we are working!

FUTURALOGISTS: When there will be a day where all browser is dead and new technology to rule the world for sharing boundryless responsible data/knowledge sharing!. (always like astorloger furturalogist are cryptic and cannot decode)

- Hope all wont behave like a futuralogist after this.

-Venkat

G Venkatachalapathi on September 15, 2011 6:33 AM

There is a system that already works much this way, with the following advantages:

1. No need to trust a cloud.
2. Browsers already support it.
3. It's easy to program on the server side.
4. 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:

1. 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.

2. 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.

levand on September 16, 2011 12:44 PM

what about using a modified version of ssh key authentication?
1. You register your public key on a well known website, the 'identity server'
2. You install a browser plugin (which contains your access data: the 'identity server' and your ID')
3. When you access a confederated website, you are automatically logged in. No captcha, no login form, no forgotten passwords...

We don't need to reinvent anything here, it already works with ssh.

The public key is stored on the identity server, the private key is on your computer, configured in the browser's plugin.

Luigi Viggiano on September 18, 2011 3:09 AM

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.

MtnViewMark on September 18, 2011 9:35 AM

I am confident that claims based authentication and authorization (SAML) could be a beautiful part of the solution, following Kim Cameron's 7 Laws of Identity.
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
http://www.identityblog.com/?p=353

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


Christian O on September 20, 2011 1:09 AM

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.

DoctorLex on September 20, 2011 3:23 AM

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.

Maksim Lin on September 20, 2011 6:09 PM

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.

James B on September 21, 2011 4:11 PM

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.

Scott Kantner on September 22, 2011 9:31 AM

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.

Merci

Ibudiallo on September 22, 2011 7:52 PM

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.

Julien Sorel on September 23, 2011 8:03 AM

I am wondering what happens if you attack the password consists of common words (mentioned in the XKCD post) with dictionary attack.

http://en.wikipedia.org/wiki/Dictionary_attack
http://en.wikipedia.org/wiki/Rainbow_table

Lix on September 26, 2011 11:58 AM

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 :P

OhMrBigshot on October 1, 2011 12:28 PM

We can cope with typing in admin passwords in OSX to do certain things after all. My Programming

Andika Nugraha on October 8, 2011 10:29 PM

I would vie for a much radical solution.

What do we really want ?

- 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).

Matthieu Monrocq on October 12, 2011 11:19 PM

It all goes back to unification, but unification of authentication is a scary thought.


"bacon the SVN!" #bacontheSVN

Daxmax on October 13, 2011 2:12 PM

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.

Sam Pearson on October 13, 2011 3:01 PM

Nevermind. How are we going to legislate across national borders?

Sam Pearson on October 14, 2011 1:37 PM

So the solution to remembering 100 passwords starts with a captcha? No thanks, I'd rather deal with the passwords.

Captchas are getting out of control. Three-quarters of them are illegible to anybody who isn't three-quarters in the bag, and the rest use ambiguous characters that could be letters or numbers. Lately I have been having to cycle them four or five times in order to find one that isn't illegible or ambiguous. The ones I really hate are the ones that require punctuation and accented characters. Last week, one actually demanded that I supply a Greek "mu" symbol. Give me a break!

Conversely, with 1Password, I can handle all the passwords I would ever want, with no sweat.

D on November 28, 2011 10:04 AM

I'm working on this now, actually. I've posted a flushed out idea here: http://rulius.squarespace.com/display/ShowJournal?moduleId=13305046&SSScrollPosition=320

Obviously, it needs some work, but I have a lot of confidence in it.

Dylan James on November 30, 2011 1:47 PM

I enjoyed the article, but I especially enjoyed the Beagle Bros mention. I was part of Beagle from 1985 until 1991 when the Apple II line was sold to Quality Computers. I miss the good old days, but I wouldn't want to give up my iPhone.

Randy Brandt on December 2, 2011 4:25 PM

Sigivald wrote:
"I mean, sure, it makes your life as a website operator easier.

Good for you. Not my problem as a user, however. I don't care about making your life easier (nothing personal!); I care about mine, and "magical browser-based just works once you give a browser your master super-password" is BAD."

...Because website operators are the only people who have to create accounts on the Internet and log on to them. Sigh.

And to Sigivald and everyone else complaining about the high risk of having a master password that if hacked will give someone access to all your accounts - you already have one, the password of the email address you used to register all your accounts, as I'll bet that you don't create a new email account every time you're register an account on a website. If someone were to hack or guess its password, he would gain access to all accounts you created across the web by using the forgotten password feature.

MartinDoms wrote:
"No. No no no no no. I'm sick of people behaving like websites are the only things that require passwords. Your "solution" offers no affordance for those of us with passwords on our Windows accounts (several at work and home), our phone lock screens, buildings, bank/telecoms telephone lines, etc etc etc. We need a password solution that doesn't require internet access. This "cloud-based" solution is completely worthless for a massive number of use cases.

And no, don't give me that crap about ubiquitous internet. Maybe in your country, but it's YEARS AND YEARS away from being a reality where I'm from."

...What the fudge are you going on about? Jeff is suggesting a solution to the problem of having to register accounts and remember passwords across the web, NOT a magic spell that will solve your daily life's problems. So why on Earth are you crying about how it doesn't magically solve problems that are far out of its intended scope? Do you send complains to companies that write antiviruses about how their software is useless when it comes to real life viruses?

Derek San on December 27, 2011 7:18 AM

Identity is not important for the modern internet. An identity token *might* be. There are two reasons for site logins. One to reestablish state between sessions to the appropriate user. Two to sell user data.

Imagine if you had to login to a tv channel to watch that channels content. TV prior to the internet the most consumed massed distribution channel on earth, provided anonymity to its users. Mostly because it was low tech, and because it was conceptually top down, viewers dont matter as long as they are watching.

I view the login problem not as a gordian knot, but as a low tech problem, which is essentially unsolveable due to the cowardice of the collective efforts of engineers who are driven by business people who just want to collect as much user data as possible.

Lets face facts, the inventors of the internet fucked this up. It was one of the first things they fucked up and we will live with it for a fucking long time.

Rendion on July 29, 2012 5:15 AM

«Back

The comments to this entry are closed.