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; https://www.mepin.com/
â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.
- 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.
- 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.
- 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 
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: http://mozillalabs.com/blog/2010/03/account-manager/
Abstracting the problem away wonât solve the problem. It will only create more complexity and more problems in the future.