Cutting the Gordian Knot of Web Identity


The password could be selected by using a hash of some private information and some web site information (private / public keys come to mind). An issue with this approach is when things change - As they can and will. You also need to be able to shift between contexts on the client side to enable more than one account per web site.


Why are we logging into websites? I log into my PC, why can’t that be enough?

Or at least, for people with multiple logins for stuff or kiosks in libraries why can’t opening my browser prompt me for a login?

Then magic SSL encrypted XML hand waving can make it all work. The details are unimportant, the concept should be “human identifies itself to the computer, human identifies itself to the browser. Browser handles all the other stuff”

We can cope with typing in admin passwords in OSX to do certain things after all. Of course then if someone works out your password, your entire online life is compromised… but that’s about as important as letting people know the PIN for your VISA card (and you don’t do that because it’d be moronic).


Frankly, the password is not what bothers me, nor what I see as the biggest time waster. It’s the damn “email verification”, which often takes a huge amount of time to get to my inbox, usually preventing me from using the website until then.

Passwords have decent solutions already, like LastPass and similar.


The browser must, unfortunately, prompt the user with a confirm dialog containing a CAPTCHA

That seriously turns me off. I hate CAPTCHAs far, far more than having a sign in.


What you’re proposing should be additions to the HTTP spec, v1.2. It would add CREATEACCOUNT, LOGIN and LOGOUT as HTTP methods. The user would configure (once) on the device their ‘cloud password locker’, which the browser/application would send in the HTTP headers. The HTTP 1.2 based web server would then return a response with appropriate id numbers or whatever if the process was successful.

Any solution for the password problem must be designed from the outset with non-browsers in mind - so it should be part of HTTP(S).

To get rid of the CAPTCHA requirement would need something additional. How about the website generates a QR image, which would need to encode some identifier for that browser session. The user can then scan the image using their Smartphone. The device completes the account creation/login operation (using the principles described above), and the web server can then use the session identifier to refresh the website.

Obviously, lots of assumptions in there.


Multiple Accounts?


Hear, hear! Though I disagree on your proposed solution. CAPTCHA’s, E-Mail verifications, usernames and passwords should be things from the ancient past already.

OpenID was developed with good intentions, but the usability and implementation failed. We have taken what’s good with OpenID and built a service which helps you to get rid of passwords;


“The browser will also automatically select a completely random, cryptographically secure password for the new account.”

Does that mean that all your passwords are now stored in plaintext on “some form of secure https cloud storage”?


Well, enabling multiple accounts should just be an implementation detail for the OS/browser vendors. You could add multiple identities each with a ‘cloud storage locker’, and when the browser reads these special meta-tags for the create account view your browser/application would prompt you to select the identity you want to use.


All in all this is a good proposal, but there are drawbacks that would need worked out before its viable.

  1. All of your internet passwords would be stored in one central location instead of many different locations. Can’t really do much except distribute this one, but its something to be aware of.
  2. If that location ever gets hacked you are screwed and will be scrambling to change passwords that you don’t know because they were generated. This is a very very very bad situation.
  3. If the central storage site goes down, you have absolutely no recourse. You cannot access anything and you cannot change passwords because you don’t know them. If this is a distributed site then this may be far less likely, but could still be an issue.

Guarantees for uptime and such can be made but we only have to look at what happens when RIM goes down to see how bad things could be. The current approach is by no means perfect, it isn’t even good, but more thought would be required before your proposal would be anywhere near viable. We just need to be sure that in our rush for less annoying security we don’t lose security.


I think that your “dream” is exactly the inevitable future! Thanks for the great article, Jeff!


I love how your “I Have a Dream” utopia has a CAPTCHA in it! haha


@Reņģis: Identity is a very important area at Mozilla and is not being thought about in the same way as a typical Labs project. The group working on BrowserID is definitely looking to get it into a shipping Firefox release.


If part of the problem with OpenID is websites deliberately eschewing it in order to “own the identity” of their users, would requiring the addition of meta tags run into the same problem?

Browser scraping of FORM elements works relatively well for autofill. Perhaps a guerilla Browser Identity system by scraping for stuff which looks like a “Create Account” page wouldn’t be so bad.


@Reņģis :heart: It is called “labs” for a reason. And many projects there are now used in production somewhere: Bespin is now the code editor in Github, TestPilot has several tenthousand installations, Sync, Personas and Jetpack are now part of Firefox Core, …

Putting the identity management right in the browser is a very useful approach. And BrowserID even offers a fallback for legacy browsers not capable of it.


First of all why does the cloud need to be a central server somewhere outside of your control? You could have a password repository that you share between your devices and you just poll your desktop to update your passwords to your smartphone or something similar.

Multiple accounts as mentioned earlier is easily handled by the browser maintaining a list of identities and prompting you for which one.

To the security issue, why do your passwords need to be stored in clear text on the cloud, whatever form it takes? Could we not have them stored encrypted with your browser password also being the key that decodes your stored cloud passwords?


I don’t know a whole lot about certificates and their applications but they seem like the perfect fit for the magic data used to identify someone. That is, instead of you still generating some silly ascii password, why not have the site issue you a cert?

Surely the whole cert system (if simplified by a suitable amount of hand waving) can bring a lot to this party?


That’s pretty much what Mozilla’s Account Manager prototype is about:


It appears the W3C is at least considering the problem:


Abstracting the problem away won’t solve the problem. It will only create more complexity and more problems in the future.