SohailH
Something like LastPass gives you the browser plugin and cloud storage. OK, it’s not your dream scenario, but it’s a start.
Something like LastPass gives you the browser plugin and cloud storage. OK, it’s not your dream scenario, but it’s a start.
You reinvented the password manager.
No – I’m proposing this should work out of the box for every website and every browser in the world, on any device.
With absolutely no configuration or thinking or plugin setup or software installation required.
(ideally using W3C blessed standards, but whatever it takes)
Another issue that you run into immediately is the use-case of multiple people using the same computer and user account, and thus, the same browser profile to access the internet, such as the public computers available at most public libraries.
Hopefully there would be some “Kiosk Mode” in the browser for this scenario, Siebren.
I dare say you’re inventing the past. Soon enough my personal bio-chip will log me in to anything I need access to automatically as soon as I touch the keyboard or the mouse.
… I dream of the day when I never need to see another password field in my browser ever again …
But from your description I read that you’ll see password field when you “Log In” into your browser 
This dream is almost done with chrome password sync.
And it doesn’t need no extra work in pages.
The problem with doing a lot of things automatically is that some people have multiple identities online. I decide on a per site basis what identity to use (my real identity or my nickname etc).
In the case where you could trust every single site with your real identity this wouldn’t be necessary but in my opinion we’re a long way from that scenario being reality thus I will be choosing an identity for every single site.
From a security point of view I wouldn’t like the above idea either, having functionality like this will enable a worm/virus to not only infect my local machine but possible spread havoc on all my registered accounts as well. Not to mention registering me for new services I don’t want…
Have you heard of BrowserID before? It’s a Mozilla project where they try to move identification in the browser. A very promising approach, that might remedy some of your outlined problems:
(When I first learned about it I thought all the way back to your driver’s license post.)
If all the passwords are generated and unseen to the user anyway, wouldn’t it be better to use public/private key pair ala passwordless ssh? then there’s less of a need for https and it’s slowness all over everywhere.
And yeah chrome password sync is a thing of beauty and about 3/4 of the way there…
But from your description I read that you’ll see password field when you “Log In” into your browser
Yes, but my computer runs for days with one instance of Chrome… I’ll gladly accept one browser login every few days!
And yeah chrome password sync is a thing of beauty and about 3/4 of the way there…
Agreed, that’s what emboldened me to propose this as (gasp) a standard.
BrowserID is a Mozilla Labs project, and I’ve come to expect their projects to get discontinued, like it happened to Prism, Ubiquity etc.
“more and more websites need to know something about who you are to work”
Ah, no. More and more websites WANT to know something about who you are, because your personal data is their money. The more you give them, the better.
You’re describing a single point of failure here, an excellent entry point for data collection, for profiling your behaviour, and to finally control your life. When someone restricts your access to this central login repository, then you’re out.
It’s the very same thing with the movement away from freely programmable production machines, to controlled consumer machines like smart phones, web pads and the like with the restricted app stores. The people are currently giving away the freedom they gained by the computer and internet revolution – and most of them seem to be happy in doing so.
Your dream WILL come true, because the consumer machines require such an infrastructure. But it will turn out to finally be a nightmare, I’m sure.
Ok, I must confess, it sounds a lot like LastPass.
It’s much more what lastpass wants to do, rather than what lastpass does, but it’s all there.
Using lastpass, it will detect a sign-up page. It will allow you to auto-fill the page with the identity of your choice and generate a strong password. Once you’re in it will detect the login pages and auto-fill your credentials. I believe you can set it to auto-login to certain sites too.
LastPass stores your credentials in the cloud, but encrypts them on your endpoint so that they’re secure. It runs on almost any device, although the degree of integration is very limited on things like iphone and android, and is usually missing from within applications themselves (spotify, any phone app), which is annoying.
Remember, our web passwords are way beyond just websites now, don’t forget our beloved mobile apps.
Are we asking for a version of lastpass that can be easily integrated with sites, browsers and apps, from both a practical and legal point of view? I guess we don’t want to make a monopoly here, so it presumably couldn’t be last pass explicitly.
Very good proposal!
What about multiple accounts for one person? Some people like to keep some accounts separated from others (eg a twitter account for a company and a personal facebook), but still be able to manage those sites within the same browser sessions.
Agreed, starting multiple browsers is a small price to pay though…
The weakness I see with your proposal is the need for some kind of cloud storage for usernames and passwords: the end user will have to sign in to their authentication provider anyways. I you have to do that, why not just use OAuth? Sure, your proposal also implies that the default authentication provider / password vault be automatically filled in the browser so that the user does not have to say whether it’s Google, Facebook, etc., but couldn’t this also be done when using OAuth?
Or is your proposal mainly about shifting the complexity of integrating with a third-party authentification provider from the websites to the browser?
I must admit I use a mishmash of techniques but LastPass is very good at achieving most of what you suggest, it can even be used with YubiKeys to give you a physical “Key” to your logins. I also universally use disposable email addresses to sign up (via Spamgourmet.com). Not only does this not expose my personal email address to spam/abuse but means I can find out which unscrupulous bar steward was prepared to sell me out!
@Sohail Hussain +1 for LastPass. There’s no way websites will ever agree on any standard as they believe my 10MinuteMail is quite valuable. I’m happy to let LastPass record the hoops needed to login a particular site and let me go on with my work (heck it even creates passwords for you, I have no idea what 90% of my passwords are any more).
Progress is not based on optimal paths but paths of least resistance. I hope Dick Hartd will prove me wrong but until then using (insert favourite password manager) will do.
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.
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/
It appears the W3C is at least considering the problem: http://www.w3.org/2011/identity-ws/
Abstracting the problem away won’t solve the problem. It will only create more complexity and more problems in the future.
From a privacy point of view, I rather like being able to keep accounts at different websites entirely separate. This kind of system might be acceptable provided that it remained entirely optional, which is impossible to guarantee.
Unfortunately, there are 2 words that can bust this dream, just like any other “secure” password mechanism: keylogger malware. You either have to intially sign into your browser, or the “cloud” identity store at some point (think public terminal browsing), and then you’re still vulnerable to man-in-the-middle attacks for stealing your online identity, which has suddenly become much more dangerous because your bank account, 401K login, etc. are all tied into the cloud identity store, so once that’s cracked, you’re toast. At least with separate passwords, you might be smart enough to protect your bank password more vigilantly (i.e.: don’t access your bank account from a public terminal).
That said, I agree with the initial premise: password proliferation on the internet is totally busted and in need of urgent help.
“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?”
Fair point, though it would make it difficult to change your browser password.
Unfortunately, I think any developer capable enough to work with such a standard is also the same developer pushing for OpenID logins. “Just use OpenID, damnit” will quickly become “Just use standard login/password registration forms, damnit.”
But frameworks auto-generating username/password stuff will be slow to migrate, or old UIs that integrate across multiple non-browser mediums will never migrate, or…
you get my drift. I say we just push harder for OpenID.
Another question that would need to be addressed is how the browser authenticates the site requesting a login.
If this isn’t secure it would make it very easy to create an automatic phishing site as the password is being sent without any user input.
You have just described LastPass.
Finally! It seriously took me about 5 minutes to create a profile (which I still had to provide a username/password for ;)) because the other sites didn’t work! That said, I do believe passwords can be abolished. Though, I don’t trust any other identity provider. There is no reason why I should be bound by some other system to verify who I am other than me.
That said, I think a fairly solid solution would be to use the PGP model that would act as a plug-in for browsers. You would have an application that would sit on your PC and it would create and manage a secret key. Profiles could be generated from this secret key and generate public keys which can be shared at will. The browser plug-in would then detect if the site is using the same authentication scheme and, if the site is authorized by you, the public key and profile would be shared with the site over an encrypted connection and you would have instant access to your sites. Granted, this would need a critical mass of user penetration to be considered useful but it would require no passwords and could be shared across devices (This could create a management headache. Though, why you would have a different address for your ebay profile from device to device is beyond me.).
The entire purpose would be to store identity profiles and not payment methods so there shouldn’t be much worry about the boogie man lurking around the corner. The only real issue is if your computer is compromised and your keys were stolen. This would also defeat keyloggers, as Izaak mentioned, as no keystrokes would ever be required to generate and pass around the keys that identify your profile. There would be no risk of mistaken identity from site to site as the keys for each profile would be unique.
Basically, I trust no corporation or institution to vouch for me as ultimately they will only serve their own interests and there is always the risk that if the “trusted” source says you’re someone different, through fluke or otherwise, than who you say you are then who are you to disagree? Eventually we must all take responsibility for who we are online and I think only we, as individuals, can do that. This might not be a perfect system but I do believe it to be in line with these ideals.
I also want to remind you that SSL is horribly, terribly, keeps-me-up-at-night broken. My browser still has 1024-bit trusted roots, which were expected to become breakable as early as 2006 or as late as, um, 2011, depending on your source. And once any of them is broken, the attacker holds the keys to the Internet. (This is in addition to demonstrated attacks: sslstrip and sslsniff, outright forged certs (the Comodo reseller snafu and hacking of DigiNotar), certain CAs signing multiple certs for “localhost”, and the unbridled “we’ll do what we were supposed to be doing in the first place, for a price” avarice of EV certificates.)
The multiple identity problem, raised above, is important to me as well: I need to select Skyborne vs. other identities at will, e.g. to write about sexuality without having any stigma from that attached to my real life.
Dare I say it? Card Spaces and InfoCards. It was very similar to your “drivers license”. It also allowed for various identity providers so you aren’t limited to 1 issuer.
There are only 2 small problems that I think prevented it from being used.
Identities were not portable. (BIG PROBLEM)
It was mostly Windows.
If you solve problem 1 then problem 2 will solve it self because web sites would start supporting it.
Of course, info cards are very similar to client certificates. I believe these can be installed on multiple PCs. However, don’t think they have the security of InfoCards due to the fact that every web site sees the same id, where as with InfoCards each web site gets a different token so they can’t match you from site to site.
BOb
Aren’t we most of the way there?
To sign in just now and post this very comment, I hit “sign in”, it asked me which credentials I wanted to use, and ta-da.
I can’t remember the last time I had to sign on to SE. I hit log in, use OpenID, and it works.
The problem I see there, AnyGould, is that your identity provider is still some third party. If you’re on the web to be able to hit a web site there is no reason any resource should be hit other than your PC for identity verification. “Trusted” identities for sensitive systems is a different concern but just for posting on codinghorror.com shouldn’t take any sort of “trusted” status and you telling this site who you are should be enough. But, this is one thing I care particularly about though so I am biased.
Your “dream scenario” sounds remarkably similar to how LastPass works now. On the downside, auto-scrape and fill of account creation and login info isn’t quite perfect. On the upside, they already store a strongly-encrypted password list in the cloud that is only decoded on the device, and it’s available on almost all devices and browsers.
They don’t have a captcha, and I don’t see what the purpose of it is either. Why bother having the browser side verify that there’s a person at the computer?
Why not just mature and use Public Key Infrastructure?
Mozilla seems to put your idea to work:
http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in
Sounds marvelous. One thing that I especially like about it is that I don’t see any reason why it couldn’t be implemented by LastPass, and they have a lovely bookmarklet interface that means they’re portable to just about any browser.
Have you considered asking LastPass if they’d be interested in prototyping a test implementation of something like this? They’d seem to be ideal since they already have the secure-password-management-in-the-cloud side of things taken care of, and users who would presumably be very receptive to even more automation. You could implement the provider part on Stack Exchange to give it some production usage.
I’ll see your xkcd comic and raise you another http://xkcd.com/927/
Already see this effect in the comments
“They don’t have a captcha, and I don’t see what the purpose of it is either. Why bother having the browser side verify that there’s a person at the computer?”
I think the point is to stop the cloud sending all your personal details to any website that requests them.
The problem is, I don’t want what you describe. I don’t want my browser holding those credentials or passing them by proxy. It’s too easily compromised or spoofed. I don’t want the cloud holding those credentials, for the same reason. Regardless of what the credentials are, I want them either in my brain or in a passphrase-encrypted store which does not directly interface with the browser.
So, your proposal needs a big “do it the old way” button.
Why do we need password protected accounts for websites at all? I can (and will) tell lies on account-creation pages as well. And, really, who cares who I am? Even with the account-based model I can easily make 42 different accounts.
No, the real solution is banging the heads of all web-devs who think they’ll need accounts against a sufficiently stable wall - until they don’t think that anymore.
Nobody with at least half a brain stores anything private unencrypted on the web. Passwords didn’t save the dropbox or PlayStation-Network users, and they won’t save you.
So, just get rid of your fake security and wannabe identification device named password-“protected” accounts.
Problem solved.
For real security use encryption. With a password. Stored in your brain.
In Belgium, everyone (over 12 years old) has an electronic ID-card. Which basically contains a few certificates which you can use for digital signatures. (E.g. paying your taxes online.) You only need a cardreader, and the software (which is open sourced and can be found here: http://code.google.com/p/eid-mw/).
I’m not an expert on the topic, but I suppose a certificate for everyone might work… More info here: http://en.wikipedia.org/wiki/Belgian_national_identity_card
+1 for LastPass.
mmmm, I agree that something must be done, but your solution seems flawed to me… You have one password to rule them all, if someone gets your master password, you are screwed, he has access to all the sites ever.
I get that like this xkcd comic says http://xkcd.com/792/ (noticed how many things can be explained with an xkcd comic?), a lot of people use the same credentials for different sites, but that’s another subject.
+1 for LastPass,
The Security Research Team at the Cambridge University Computer Lab came up with a more radical idea to represent utopia, named ‘Pico’ ( http://www.lightbluetouchpaper.org/2011/03/27/pico-no-more-passwords/ ). Proposing a clean slate approach.
Another solution my guts believe is safe is (I have no formal proof) to replace
http://…/signin
by
https://…/signin?uid=123456798123456798…
With the uid to be a huge random unique key.
TLS makes sure nobody can read the url, so your uid/ukey is safe on the wire.
Bookmark it.
Make sure your laptop is not stolen. (anyway…)
Done.
Lastpass does a lot of this for me, although when it does mess up, it dies hard. Thankfully they make it pretty easy to manage the accounts it stores, and can handle multiple accounts well.
Also, I don’t know about him, but in my world, the sites I care about all limit login attempts or speed, so you can’t brute force - the “1000 guesses per second” problem is solved by not having the same password on every account; use different ones on banking and Important accounts - none of which will tolerate that sort of behavior from outside, and a shitty generic one on useless sites like forums because who gives a damn about forums.
And lastly, the Bad People don’t care about my account. They care about getting “easy” accounts; the people who use “Password123” and the like are all screwed.
On your suggestion - I absolutely reject any centralized system where a single point of failure breaks everything and a single security issue compromises everything I do.
Have fun pushing it - I ain’t taking it.
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.
I don’t want to have to give Someone Else’s Computer my Master Credential Authorization to, say, play Kingdom of Loathing.
No. Just no.
For those wondering about still needing to sign in to the browser or cloud service, this is where something like a smartcard, keyfob, or other physical authentication device would come in handy. They are unappealing in today’s world of separate accounts on every site, but under this scheme (when paired with a quality account recovery service) it makes a lot more sense.
I’m curious about how we would prevent a malicious (or temporarily hacked) web site from showing a specially crafted sign-in page to the browser, and having the browser send along your private information to the wrong place without you every noticing. It seems… exploitable.
Also: captchas are not appealing to me for this. But I reference my first point: combine it with a hardware security key, and maybe the hardware key allows you to bypass the captcha.
Couldn’t agree more. There has to be a better way. And, there very nearly is with OAuth. However, and this is a pet peeve, whenever I use a OAuth account to log in to a 3rd party site, they require far more entitlements than they need. Thus making me nervous, and resorting to site specific user/passwords.
To enable me to post this comment. I logged in with my Twitter ID, which asked fir the following entitlements (this is the actual text):
• Read Tweets from your timeline.
• See who you follow, and follow new people.
• Update your profile.
• Post Tweets for you.
What a joke!!!
A little more respect, and we’d already be there with a Internet identity.
I get that Jeff’s saying a browser standard and not a plugin like LastPass, but WRT @Christopher and some of the other “LastPass” posts: one of the nuances about LastPass is that it only stores encrypted copy of your password database in “the cloud”. A local copy is downloaded to each device using it, and is accessible offline. So it supports “occasionally connected” scenarios, though obviously you can’t sync up new passwords from other devices while offline. The encryption is AES256 I believe, so it should be good until quantum computers come out next year. 
Seriously, Jeff, look at LastPass if only for the technical details about what would be necessary to implement something like this. I’d love for it to be standard, better integrated into websites, and free-er, but it really follows the spirit of what you’re saying here, I think.
Another kink in your plan is that not only websites need passwords. As a consultant, I have VPN passwords, AD accounts, 3rd party apps. Not to mention personally, I have PIN codes for bank cards, membership cards, etc. So, you’re right that it all boils down to identity, but a full solution has to be bigger than a web browser.
Is argue that TSL (aka SSL) is not broken. The “trusted authorities” model is broken, which typically only effects HTTP+SSL for browser communication. WebId is not affected by this, nor is the public+private key system in general. We should just move to client keys period, which is all the “trusted authorities” are emulating because of the lack of processing power in the past.
A bit of a low-tech version of what you are talking about, but it’s worked well for me for years (Password Safe + DropBox): http://mooneyblog.mmdbsolutions.com/index.php/2010/04/16/password-management-for-dummies-and-developers/
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.
Wouldn’t this tie me to a single browser? I use several browsers on several devices, and I need access from all of them.
Jeff, you are a genius.
Yes, yes, yes. I have a text file with my passwords/usernames and I have to refer back to it when going to another site. It’s a gigantic pain in the ass.
This is a major restriction of the web, versus the desktop. But I’d like for the web to act more like the desktop. When you logon to your desktop, you input your username/password and are able to access all programs without a hitch. This is what I’d like for the web later, as you stated, having an ID/Password and accessing any site in the world on any device.
There is however, one big catch. The only way it’s possible is if either:
Realistically, the more websites we go to, the bigger a problem this will be. I know I’m not the only one that goes to tons of forums/blogs/e-com sites and gets pissed off when you have to click the “forgot password button.”
CAPTCHAs don’t work well in any case. Spammers just pay people to solve them and computers are better than humans at deciphering mangled text/identifying puppies/etc once trained.
http://bitland.net/captcha.pdf
The number one biggest concern I have reading your description of this is when you say the word ‘etcetera’ in this sentence: “retrieves the user’s standard information fields like name, email address, etcetera from some form of secure https cloud storage”. Sites are all the time asking for information I may or may not be willing to give. Especially when I’m trying something out. So maybe I start with a mailinator address and a fake birthday, and then based on the usefulness I’ll sign up for a real account. But even then, there’s not much chance I’m giving my real phone number. I don’t want any sort of automatic data pull happening from some cloud storage. I have to control what data I share, 100%.
I remember reading an article by Doc Searls back in 2005 where he completely missed the same point: http://www.linuxjournal.com/article/8357. Identity information is essential… valid demographics are often optional. If the system doesn’t allow me to remain semi-anonymous, fake data, or outright lie when I’m asked for information that I don’t want to give, the system won’t gain acceptance. Identity and demographics are different and have to remain so for any system like this to work.
I agree with the approach above using SSL certificates. Using a single cloud solution is a single large point of failure. If Amazon Service or Google ever goes down (and they both have) then the internet is broken. I put a more formalized solution up for the method described above using SSL and a private key store.
Sure sounds a lot like CardSpace.
Why not using fingerprint scanners?
I think they’ve gotten pretty cheap.
I just don’t see this as such a big problem as you point out.
I have very few websites where I have a unique username/password. Basically just Google, Facebook and Amazon.
Almost all remaining sites support my Facebook account or OpenID in some other form (posted this comment through my Yahoo! account).
What @Sigivald said:
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
+1 (mamy times)
Sounds scary that there would be a database of the passwords of everyone in the world…
And I agree with most of the comment mentionning LastPass to be as close as can be from your proposition…
Why do people prefer lastpass over 1password?
How about this: you have a PGP key pair installed on your machine. Your username (everywhere) is the public key. Your password is the url (or something in a meta tag), encrypted with the private key. Both base-64 encoded. You can also install that certificate on the cloud, in which case you would get each password by logging in there, so you wouldn’t need to install the certificate when you’re a guest. In other words, you’ll only use the cloud when you’re not on your default machine.
Isn’t that simpler, and just as secure?
Any chance you will consider adding authentication via a X.509 certificate as an additional option on stackexchange? It sure seems like this should be pretty easy to implement. It seems like it should be as useful for proving the identity of someone as trusting 3rd party identity providers, or cookie based authentication. You already support multiple authentication providers adding another should be easy.
Just setup a page, which requires a certificate. If you have never seen the public certificate before, ask the user if they wish to associate the certificate with an existing account or create a new one, store the certificate for future logins. If you have seen the public cert before, then look up the account details and log the user in.
I would suggest that you should not care about what CA the certificate is signed by. Just accept any certificate signed by any CA, or self-signed. If you don’t spend time trying to verify anything to do with CAs, certificate based auth basically just becomes trust on first use.
The technology you’re looking for is called “Kerberos”
Internet driver’s license or another third party centralized authentication. With government approbation or / and control = Instantaneous worldwide censorship.
Also attack that password combining random words from a dictionary. Your entropy become useless in no time.
Scan your eye/fingerprints as your identity. I hope in near future all computers/devices will have camera and browsers should be able to scan your eyes/fingerprints and use that to identify yourself
Jeff - what exactly does the browser integration get you over the current state of affairs at StackExchange? I click to ‘log in with Google’, and I have to confirm the first time, after that logging in seems to be just transparent without any prompts.
Google should buy Lastpass and make it a default in Chrome and Android. Lastpass is great on the Desktop, but sucks on the iPhone because of a lack of important public APIs on iOS.
It would be great if all the Internet switched to SSL, and used client certificates to identify people.
You need a revokable and replaceable token. The site sends me a random string (there was an Ansi token that used DES). I type it in or have something like a yubikey maybe with pin or fingerprint (and/or clock) in a usb port. It returns a cryptographic response.
Something like this exists with cell phones where you can get texts or voice responses.
Note that from the user’s perspective, you have reinvented SPNEGO.
This is implemented in all interesting browsers, and is how Microsoft implements Kerberos in IIS.
I have a feeling that your solution is implementable on top of the existing SPNEGO infrastructure, which is IE, Chrome & FF
I agree - aren’t we all sick to death of passwords. Well how about a passwordless solution. One which requires you to identify yourself through SSO or OpenID but then authenticate yourself securely through a ‘secret’ code sent to your browser and validated by your mobile phone. I won’t say anymore - we launch this service next week and we will revolutionise this space. Check it out. LiveEnsure. http://www.liveensure.com/ The key principle is ’ identification is not authentication’ . !!
What about PKI? Why don’t more sites support this? Especially banks. In the absence of more universal adoption banks should be acting as CA’s and issuing PKI certificates for secure access to their own service. Browsers already support it and it works tremendously well.
You know what I would love to see? Smart Card driver’s licences with identity certificates on them.
Jeff, might I point you to this XKCD comic? http://xkcd.com/927/
I posted a message here recently, but it didn’t even get to the messages, not to talk about that I have to log in.
The problem with passphrases is that MANY well known sites don’t allow spaces in passwords (twitter for example - you would have thought they would know better).
And the number of sites I’ve come across that won’t let me use symbols in a password, or limit the password length to like 10 characters. I usually go for 20+ totally random characters/symbols using (the awesome) lastpass password generator, but it feels like the websites are against me. It’s like they don’t want us to be secure.
Seriously - if I want to create a 256 character password then freaking let me (I know there will be collisions shorter than that).
I think the Android os locks the device the best: It lets me lock it with drawing a gesture with my thumb and that’s all needed to unlock me into Android and then everything. So there is no password and still a lock.
I like the idea of software and apps acting “on user behalf” i.e. the software is allowed to act on a user’s behalf and that can mean a lot of things like predefining accounts for services that a users might like so that a user can be already “registered.”
A programming problem is these different user models when a facebook user and a google user can be very well defined and no interaction or relation was defined. So I think internet communities should “sync user data” and if you allow a software realtime uptimes then that’s as easy as pushing the button if already logged in from a known account.
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.
