May 22, 2008
As we continue to work on the code that will eventually become stackoverflow, we belatedly realized that we'd be contributing to the glut of username and passwords on the web. I have fifty online logins, and I can't remember any of them! Adding that fifty-first set of stackoverflow.com credentials is unlikely to help matters.
With some urging from my friend Jon Galloway, I decided to take a look at OpenID. OpenID aims to solve the login explosion problem:
OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.
You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. And best of all, the OpenID technology is not proprietary and is completely free.
In the spirit of Show, Don't Tell, here's how it works:
Let's say you're visiting a new website for the first time. As you browse around, eventually you'll do something that requires more than anonymous guest access. So you'll get shunted to the "create a new account" page, in whatever form that takes. I'm sure everyone reading this knows the drill. But if the website is OpenID enabled, you don't have to go through all the typical rigamarole necessary to create a new account. Instead, you can enter your OpenID login:
I'm going to indulge in a bit of hand waving here and assume that you already have an OpenID login. It's not such a terrible stretch, honestly; every AOL and Yahoo user already has an OpenID login even if they don't know it yet.
OpenIDs are technically URLs. Here are a few examples:
That's one usability problem with OpenID: you have to remember a relatively complete personal URL that no two OpenID providers define the same way. Which compares unfavorably to, say, remembering your email address. There are shortcuts around this that I'll describe later, but for now, there's ID selector, which provides a reasonably friendly UI for building an OpenID login URL.
If you enter the right URL, you'll get redirected back to your OpenID provider, where you'll enter your single set of login credentials.
You'll be prompted to add this site to your provider's list of "trusted sites" for your account. Once you do this, you can bypass all of these steps the next time you're on the site.
And, finally, you're logged in for the first time!
If that seems like extra work -- and remember, I'm not counting the time it took to set up the initial account at ClaimID, either -- well, I won't lie to you. It is more work. But it's worth noting that:
- The cost of account creation at your OpenID provider can eventually be amortized across dozens of sites which will all accept those same credentials.
- After the first OpenID login at a particular site, assuming you've added that site to your trust list, subsequent logins are literally one-click operations.
It's not exactly frictionless, but it's a heck of an improvement over having to remember 50 different usernames and passwords for 50 different websites, wouldn't you say? I think it compares quite favorably with the current champion of frictionless communication: anonymous comment boxes. They typically have three fields to fill out: username, URL, and email. OpenID requires only one. Your provider can proxy your URL and email back to the blog automatically from your provider profile, if you choose a smart provider with attribute exchange support.
Which brings me to the other problem with OpenID. The quality of your OpenID experience is heavily influenced by the provider you choose. For example, Yahoo! is smart enough to work even if you enter nothing but "yahoo.com" as your OpenID URL. That is, assuming you've enabled OpenID support for your Yahoo! login. Providers can also offer unique functionality that sets them apart, too. For example, SignOn.com allows the use of Information Cards in Windows, so you can log into a website without ever typing in a password! It's a bit of work, as you have to associate the Information Card with your provider account first, but I tried it, and it works as advertised.
My experiments with OpenID were quite positive, but all is not wine and roses in the land of OpenID. Stefan Brands identifies some potentially large problems with OpenID, backed by exhaustive references:
- Phishing. A malicious site could visit the OpenID provider URL you gave it, screen-scrape your login form, and present it locally, intercepting your login and password. However, if you choose a quality OpenID provider, they'll use SSL and a high-grade certificate so you'll have some confidence you're not being fooled. Yahoo also offers anti-phishing image watermarks for OpenID logins, as well.
- Privacy. Your OpenID provider will know, by definition, every site you log into using its credentials. So I hope you trust your provider.
- Centralized Risk. If your OpenID account is compromised, every site you used to access it is also compromised. I'm not sure how much riskier this is than having your email credentials compromised, as many (most?) sites allow you to send a password reset to your email address.
- Lack of Trust. The OpenID providers provide no identity checking whatsoever. It's sort of like those generic "identity cards" you can obtain online, which are pretty useless next to, say, your Driver's License, which was issued by a local governmental authority. What if Fake Steve Jobs created a fake OpenID purporting to be Steve Jobs, or a fake OpenID provider?
- Additional Complexity. Your login now involves two completely different entities: the website you're attempting to gain access to, and your OpenID provider. You have to understand this new relationship to troubleshoot any problems with your login -- and the OpenID provider has to be up and running for you to log in at all.
- Adoption Inequality. It's easy for AOL, Yahoo!, Six Apart, and Technorati to become OpenID providers -- but what good does that do you when there are very few OpenID consumers? As Dare points out, there are no financial incentives to accept credentials from your competitors, but there are certainly plenty of incentives for driving account creation on your own site. For now, I expect OpenID to be driven primarily by small applications and sites that don't have millions of dollars of skin in the game.
As I mentioned above, I feel most of these criticisms can be mitigated by picking a quality, trustworthy OpenID Provider. Particularly one that uses SSL. Since it's an open ecosystem, I'd hope the more reputable and reliable OpenID providers would rise to the top. And consider the advantages: as an application developer, you no longer have to store passwords! That's a huge advantage, because storing passwords is the last business you want to be in. Trust me on this one.
I also found Jan Miksovsky's criticisms of the user experience of OpenID -- as of 6 months ago -- fairly damning:
And all this is for -- what, exactly? To save me from having to pick a user name and password? As annoying as that can be, it's just not that hard! Remembering an arbitrary user name does cause real trouble, but simply allowing email addresses to be used as IDs can solve almost all of that problem. As more and more sites allow email addresses as IDs, the need for OpenID becomes less compelling to a consumer.
For the time being, I can't imagine a sane business operator forcing their precious visitors through this gauntlet of user experience issues just for the marginal benefits that accrue to a shared form of ID. I've read numerous claims that all it will take is for someone big like Google to support OpenID to crack this problem open. Unfortunately, there's no business of any size that can afford to direct their traffic down a dead end.
Most service operators will, at best, offer users a choice between using a proprietary ID or an OpenID, creating a terrible economic proposition for a consumer. Faced with the proposition of: 1) struggling once for thirty minutes to struggle through a process they can barely understand, or 2) spending two minutes on every new site breezing through a familiar process they've done countless times before, normal busy people will choose the familiar route time and time again. I'll bet anything that most people will keep going for proprietary IDs, further deferring the network effects possible from OpenID adoption.
Perhaps the most compelling point Jan makes is this one: it is a bit odd to ask users to associate themselves with an arbitrary URL instead of an email address. I definitely saw some rough edges in today's experimentation, but I'd say the user experience has improved since Jan looked at OpenID. That's encouraging.
I realize that OpenID is far from an ideal solution. But right now, the one-login-per-website problem is so bad that I am willing to accept these tradeoffs for a partial worse is better solution. There's absolutely no way I'd put my banking credentials behind an OpenID. But there are also dozens of sites that I don't need anything remotely approaching banking-grade security for, and I use these sites far more often than my bank. The collective pain of remembering all these logins -- and the way my email inbox becomes a de-facto collecting point and security gateway for all of them -- is substantial.
If you're a software developer building an application that requires user accounts, please consider using OpenID rather than polluting the world with yet another login and password. I also encourage you to experiment with OpenID as a user. Create one. Try logging in somewhere with one. If you don't like the experience, or if you agree with one (or more) of the criticisms I listed above, how can we collectively fix it? We desperately need a solution to the login explosion, and right now the only thing I've seen on the horizon that has any kind of critical mass whatsoever is OpenID.
If we can't make OpenID work, at least for run of the mill, low-value credentials that litter the web in increasing numbers -- what hope do we have of ever fixing the login explosion problem?
Posted by Jeff Atwood
Here's a simple idea...
Extend the mail protocols. Instead of signing up with a Id provider, everyone either has an email account, or can get one for nothing.
When a site needs to identify you, they ask for your email address, forward you to that server for verification, and then you can be forwarded back.
The infrastructure for determining your mail server from the hostname already exists. Further if there is any one provider that already knows everything about you, it's your mail host.
This isn't complicated and could easily reach a large audience.
If you've never seen Simon Willison's "The Implications of OpenID", drop everything and watch it now. It explains the benefits and drawbacks in such a clear and convincing manner, bringing up points that I haven't come across elsewhere on the net. Check it out here:
To be honest I'd rather you used Microsoft's Passport or the Google API or something else that I likely already have, OpenID although a great concept has actually just created another Id I need to remember
I really wouldn't feel safe having just one login for all my accounts. If it gets compromised, then everything gets compromised. I'd rather have separate login credentials for each account/website. Remembering these credentials is not hard at all either, even for dozens of accounts.
Just invent a quick algorithm you can do in your head, which produces a password based on some master password and the purpose of the account. For example, if you choose a teacher's name as your master password for all accounts (e.g., Mrs. Krabopple), then for logging into Amazon your account password could be something like AmaKraboppleZon - throw in a little 1337 $p33k for numbers and symbols, and you have a complex password that's hard to crack but easy to remember.
I have been fighting with this same problem. After years of my internet activity I have collected quite impressive amount of different user names and passwords I had to remember... and I have been trying to, really hard...
I know know that I shouldn't store them in in word document (even compressed and passworded - brut-force still rules) ad I decided one day that I will write an app helping me to solve this problem.
Maybe it will help you as well. It is free.
http://www.aristo-samar.com/pc.en.aspx (seventh project down)
If you will like it I will appreciate your comment.
Also, it's kinda cool that you can put two link tags in your header to use your own website as a "shortcut" for your OpenID URL. Assuming you have a website, and you're comfortable with the whole URL-as-identity concept.
So in other words, I could just type in "codinghorror.com" and press "login" and get the correct OpenID provider, etcetera.
Well, you can also choose to always pick the same login, and you only get a password problem. And you can choose the same password also, provided the site let you choose.
Being registered on fifty site does not mean you really need fifty different password and login ...
It's also important to realise that there's no reason for an openID provider to require password authentication. This is alluded to in the post but not in a big way.
For example, your provider could issue you a challenge via IM
Visit LiveJournal (for example)
= Enter openID, Click login
= Receive an IM from openIDBot "livejournal.com requested a login for openID http://myprovider.com/myopenid. Reply 'yes' to allow login"
= Type 'yes'
= Logged in
I believe OpenIDs should not be a URL system but rather an e-mail address system. In my case, 'gmail' would be my OpenID provider, and I would use my e-mail address to authenticate myself. Like you said, sites already defer authority to the e-mail address provider with password retrieval/resetting features, so it's no riskier.
Being registered on fifty site does not mean you really need fifty different password and login ...
1) I can use my email address as the login
2) I can use my preferred password as the password
.. on all 50 of those sites. The odds of that seem extraordinarily slim to me. Sites vary widely in what they will accept as logins and even passwords (complexity rules, length, etcetera).
And then let's consider what happens if I want to change my password. Do I log in to each of these 50 sites and change it?
That said I totally agree with Jan: the "competition" is between OpenID and the inertia around existing per-site login systems.
It might just be me being paranoid, but I don't think openID will work until a small fee is taken to create a user account (thus creating an almost spam free system). I'm talking about a fee of maybe $0.50 for an account, just to stop spammers from creating hundreds of accounts (just cos it will be too expensive).
But then again, who is willing to pay for using it?
1Password FTW! Its a super-keychain that remembers webforms, identities, credit cards, etc, all locked down with a single password. It even adds a button to browsers (and NetNewsWire) for easy form filling. Not free and Mac only, but worth it. And it syncs the keychain to an iPhone or Palm. I think powerful local apps like that, maybe combined with random number one time pass tokens are the future for secure and mostly convenient logons.
Umm... I use Firefox. It remembers all my login and passwords. I have different credentials for every group of page I use, so if ever one account is hacked, these logins might work on some other pages of the same kind, but they will surely not work on most other pages I use regularly. Why should I have to remember these? FF has a Master Password. First time I go to a page that requires login, FF prompts me for the Master Password. Once I typed that it, it will pre-fill all login forms for me.
I can also look up what the remembered password was, just in case I have to.
Further I have a nice extension installed, called Secure Login. What that's good for you ask? Well, first of all, it will not auto-prefill forms. Why not? Because as soon as FF puts something into the login fields, JS code could read the values from there and transmit them over the net. This is too insecure. Instead SL will only highlight the login fields for that it knows data is available (in orange, but you may change the color in the prefs) and only prefill it, if I hit a shortcut (can be changed to whatever you desire) or if I klick the SL icon, either in the status bar (if shown) or in the navigation bar on top (you can configure to show it on either bar, both or none). Another advantage of this extension is: If you have multiple logins for a site (and here is a big advantage of OpenID! As you need different OpenIDs for that), SL will not prefill the most likely one, as FF does by default and only change password to another one if I change login, it will show a sheet window with all available logins and asks me to pick one. Last but not least, I don't have to click on a login-button after SL prefilled the form. I can configure SL to submit the form automatically as soon as it prefilled the login data.
All in all: Using Firefox with a Master Password (making sure your login data is encrypted on your HD) and adding the Secure Login extension prvoides a very easy, painless and secure way to manage your logins and in the end, the only password you need to remember is your Master Password.
How about setting up your personal OpenID provider? If there's anyone you can trust, it should be yourself I guess. Then you can add as much security you want, plus your OpenID looks cool as well ;)
At the last count, I had 56 logins to keep track of. Not just for websites, but also work-related. For most of these logins, I DON'T EVEN KNOW THE PASSWORD. Instead, I used KeePass to generate and store a (strong!) password for me, and use the auto-type function to login. Passwords are stored securely (AES) encrypted. The application and data are stored on my EDC memory stick.
OpenID is nice, but the only real solution in my view is a workable public key infrastructure. Something I happen to be working on :).
I've spent the last few days implementing OpenID on our group of websites.
In the end, it was reasonably easy to integrate OpenID with our existing login system. instead of username/password in our database, it was username/provider - which kept our unique username system going, across multiple providers and our own users.
Wether it's the future I'm not totally convinced. It is more difficult initially to remember your string, and ofcourse, you sitll have to remember your username and password for your provider.
Your point on the providers is an important one. Wordpress is atrocious. If you are not logged in, it tells you to go a different page (with no link to that page) and login, and then try again. Others worked properly - even AOL.
"the only password you need to remember is your Master Password"
That's until you move to another computer, in which case you're a little screwed (and lot's of people log in on lots of different computers all the time).
With regards to using email over url, it would be preferable from the users perspective I guess, but how would you implement it? URL's are used because the service can fetch the HTML from it, parse the data etc. How do you easily do that with email that works across all emails? It would be very difficult.
A lot of the non-dedicated providers (providers that offer other services) like LiveJournal, Vox, flickr, blogspot, technorati etc. allow the users profile page to act as their OpenID URL. This means that if, for example, I were a LiveJournal user all I need to remember to login is the same blog URL that I give to people all the time.
So when are we going to see OpenID on CodingHorror then? ;)
"Wordpress is atrocious. If you are not logged in, it tells you to go a different page (with no link to that page) and login, and then try again."
I suspect that's an anti-phishing precaution.
"My problem: I have multiple OpenID IDs. I had an account with Yahoo, an account with AOL, an account with Livejournal, and so on. So now I have several "single" sign-ons. There's no obvious way to consolidate all of them together into the mystical single sign-on."
That's because all of them are talking the talk but not walking the walk. As users we should accept nothing short of full a href="http://wiki.openid.net//Relying_Party_Best_Practices"Relying Party/a status. It's particularly sad in LiveJournal's case, given that the technology originated there.
For a user, this is no more or less secure than using e-mail authentication. I don't think it would be any more onerous to set up another fake identity with an OpenID provider than it is to create another Hotmail/Yahoo/Google account.
In terms of being monitored by third parties, this is a little more explicit than the information that could be gleaned from having your account scanned by your mail provider, but the information it is possible to gather is the same.
One downside is that (at least) two servers are involved in authentication - which may lead to difficulty for users signing in at peak load. The OpenID servers become points of failure during login too, though this would affect a low number of users at any one time.
I think the biggest hurdle is perception - people don't know what OpenID is (I didn't), how to get one or how it is different to MS Passport. The biggest hurdle will be in developing a really good FAQ. Maybe get Joel to write an essay on it.
What if an existing popular sites made its accounts OpenID? Bam, your Google/Youtube account is now an OpenID. Sites can list that they accept "OpenID/Google account".
It'd be much more straightforward if e-mail addresses were automatically parsed as potential OpenID accounts. Suppose for example that the site checked firstname.lastname@example.org for an OpenID server at example.com.
I'm willing to bet though that most people already DO use the same e-e-mail address and password across multiple sites. It's not centralized (and not perfect in terms of security), but it's simple for the user. Ultimately I think if the user experience is to be improved it needs to make OpenID a lot more straightforward and transparent to the user.
I've been getting quite heaviy in to openId recently as I see it as a fundamental forward step in consolidating online identity. I've written a few posts on the topic over on my blog (...davidwhitney.co.uk/content/blog/index.php/2008/03/26/fractured-online-identities/ , /2008/05/06/stop-holding-my-data-hostage-data-ownership-and-web-30/ and /2008/05/20/web-30-data-silos-and-identity-portals-overthrowing-social-networks/ - mangled to avoid looking like link spam!) and I'm in the first few stages of trying to design an identity controlling platform to centralise personal data and feeds hinged on open id.
I really hope that open id will turn into something that users control on their own (perhaps some kind of physical home device that controls your identity that you plug in to the internet) allowing a user to have complete control, whilst the value proposition for consumer websites is that they don't have to worry about user data, just add the value and the services they perform best. If this becomes as easy as setting up a facebook profile then it's a huge victory for users. Obviously this isn't appealing to data warehousing entities, but perhaps it's a power they shouldn't have over their users anyway.
It really just seems like handing the user control of their identity back is the first step to letting users define what data regarding them the internet has access to, and that's nothing but a good thing. There's a little bit of setup involved, but really it's no harder than setting up webmail, and most people got the hang of that pretty quickly. It's almost an easy sell when you tell people that they only need to maintain profile and contact data in one location- people like ease of use because repitition is boring.
I personally believe people should control the feeds of all data related to them, but that kind of integration is probably a long way off.
I've got to say, I really like OpenID. I especially like how I can just use my blog URL as my ID, and only have to log in once.
As was mentioned above, the idea of setting up one's personal OpenID provider is quite interesting.
This is like Paypal with no money involved. Yes, it is a good idea, but I don't know how good.
@anon everyone else who says just store it in your browser.
Go download cainable or if your in firefox go to Tools - Options - Security - Show Passwords Show Passwords (bottom right) - Yes
How do you feel about storing your password in you browser now?
BTW: I am a FireFox fanboy, I just think people should know.
WOW after the dozens of times I've entered the 'Captcha' here I managed to get it wrong twice today.
OpenID is a nice solution but most people just save the password or use a manager.
I've tried it, and its a freaking pain in the arse. Never tried it again. Too complicated. At least MSN Passport (live id now, or whatever MS has rebranded it to this day) at least worked seemlessly.
And btw, doesn't this seem EXACTLY like using the same password for every site.
Say, isn't that supposed to be bad???
It is good that Content Management Systems like Drupal are taking a lead in this regard.
OpenId lets you choose who you trust to authenticate you. Sites implementig OpenId simply do not care who you trust - that's your responsibility (kiinda like your password is!). That's why OpenId is a good idea.
I long for the day when I can log into everywhere using my email address, and all chat networks are linked together allowing me to speak to friends on MSN through Skype, or GoogleTalk, etc.
I want a single online identity that can be mine, and used everywhere - rather than having to sign up to everyone's blog to post replies, host photos or whatever.
Jeff, after watching Dick Hardt Identity 2.0 presentation I see OpenID as a mere step for a more sane Identity Management Paradigm...also, their mozilla plugin Sxipper (http://www.sxipper.com/) do tend to make things easier.
"OpenId lets you choose who you trust to authenticate you. Sites implementig OpenId simply do not care who you trust - that's your responsibility (kiinda like your password is!). That's why OpenId is a good idea."
No, that's one of the reasons it's a bad idea. It means that if one bad site manages to get your password, then all sites you have a login to will be open to the bad site. In effect, it means that if you compromise the system, you compromise all sites a user has access to instead of just one.
@MDRisser: Try KeePassX (cross-platform open source port of KeePass Password Safe). The only issue is - how secure is your KeePass password? What if you lose your thumb drive? Will someone be able to crack your password by guessing it, dictionary attack, etc?
@Aaron G: Choice makes OpenID so great though - YOU get to choose a provider you trust, you aren't reliant on just ONE company to do the right thing for you and being locked in if things go south. A decent OpenID provider will provide banking-grade SSL security and multi-level authentication, making it almost impossible to hack your account unless they either (a) have access to your computer, or (b) have access to you (ie., someone you know). Not even banks provide that level of security with online banking. You need to look around/into this more, because the lock as you refer to it, well it's pretty damn good.
@PaoloB: Say you have 50 accounts. That's 50 usernames, 50 randomly generated ~160-bit passwords to remember. Most people would struggle with that. (Obviously I'm referring to a security-conscious person here - not someone who uses a couple of usernames/passwords for everything!)
@JAtkinson:  Clear cookies  Clear form data OR use a different computer. uh oh. Plus, most websites that use the "remember me" option expire the login after a couple of weeks at most.
@Vinnie: Great point! And how often do we sign up for an account somewhere, then after a while... along comes the spam. They've sold our email address (indication of poor trust) OR their database has been hacked (indication of poor security). What's to say that our password hasn't been acquired as well. A decent OpenID provider will eliminate these issues.
@Keshi: That would be extremely rare. Almost never see a site change its domain name. Even if they did, a decent provider wouldn't change the identity URI that people use.
@Christian Nunciato: Yes, but you still have that overhead every time you sign up for a new account of entering all those details YET again.
@Ian00: You trust a company every time you create a new account though.. how is this much different. Except with what you're alluding to, that trust is fragmented across possibly dozens or hundreds of sites instead of just one.
Everyone needs to go watch Simon Willison's video, whether you love or hate the OpenID concept, whether you use it every day or don't even know what it is. It answers all your questions.
Time to get off this merry-go-round!
@Eric Florenzano: Simon Willison hit the nail on the head with that presentation - it's perfect. Everyone should watch it, especially the critics, it's completely invaluable.
@bandini: Any security expert will tell you that this is a terrible idea. If your login details are compromised, then every single account you have will be compromised because they have your username and password. (Yes, I know what you're thinking: 'but with OpenID...' - read on!)
Furthermore, half the time using the same login credentials don't work. Usernames can often be taken, email addresses can't be used as usernames on some sites, and password rules always vary. I always try to use 24 character passwords with combination of upper/lower-case characters, numbers, symbols - but some sites, even banking sites, will often only allow 8 character passwords.
Using an email address as the URI for your OpenID identifier would seem a logical progression, but email addresses often change. There are millions of people with free Yahoo!, Gmail, Hotmail, etc accounts - and these shut down after inactivity. Plenty of people (unintentionally) let them expire. Many others use their work email address for everything, but what happens when they change jobs? Email addresses are too transient. Something of a more permanent URI is needed - thus the URL. With delegation to your website or blog, you can have one address forever.
Regarding security, several of the "big OpenID players" are looking at security options that far surpass that of one username/password for every site / "email me my forgotten password" emails. eg., myOpenID uses CallVerifID to call you on your mobile phone when you log in. Client certificates are also an option, as are (CardSpace/InfoCard) Identity Cards. So with this particular provider, unless someone has your OpenID URI AND your mobile phone AND is at your computer to gain access to the client certificate (AND optionally the ID Card), NO ONE EXCEPT YOU will be able to log in to your OpenID account and any websites that you use OpenID to log in with. Traditional per-website login credentials simply cannot match this level of security.
Another example regarding security is the VeriSign Personal Identity Provider. You can purchase for about $5 (through eBay/PayPal) a fob that will generate a unique one-time use token for when you log in, in addition to your OpenID URI and password. Again, someone would need to gain access to your URI AND password AND fob in order to gain access to your account.
With awareness and adoption ramping up, it is simply a matter of time before this becomes the norm. People are afraid because this is something new. If OpenIDs were around in the early 90s rather than username/password/email login options, we wouldn't think twice about it.
Find a good provider (myOpenID, claimID, VeriSign PIP are some good ones), have a play around, and enjoy. It does make life so much easier!
"There's absolutely no way I'd put my banking credentials behind an OpenID"
Having my banking credentials behind OpenID would be great, PROVIDED that my bank also asked for my banking password AFTER I have logged on with OpenID. It would stop most risk of phishing as a fake banking site would make my OpenId ask me if I trusted the site.
(Also I would not have to remember by bank acount number.)
@Ian Ringrose: great point. +1 for me, but only if the OpenID provider had exceptional security (SSL, client certificates, multi-level authentication)
I agree with Fake.
The only way to solve it would be to have some sort of browser technology that encrypted the password before passing it to your OpenID server. So, when you create an openID, you give it a password, and it gives you a key that you put into your browser.
When you go to login, you press something on the browser, it takes the site name, your key and your password and creates a hashed value that the site would pass to the OpenID box to authenticate.
To be honest, you may as well use something like Keepass.
Are you sure OpenID is 'Worse is Better' and not more 'Architecture Astronauting'?
I think multiple logins based an single email address is certainly the 'Worse is Better' solution.
I see some people talking about password repositories such as those built-in to Firefox, but as another person has pointed out, that's no use if you move computer.
A middle ground is to use a password hasher add-on like pwdhash, password_hasher, or similar. These basically create a secure hash (numbers, letters, punctuation, etc) based on a master password and the domain-name of the site you're accessing (e.g., gmail.com, livejournal.com, whatever).
For example, with pwdhash, all I need to do is press F2 with focus on the password field before entering a password, type in the pass then click the login button. The add-on hashes the string entered into the password box before the form is submitted.
If you're not near a computer with the addon, pwdhash (and probably others) have a web-site that you can use to generate the hash and copy/paste it into a password field. Providing you have a fairly unique ID, then all you need to remember is one password, but all the sites logged into have different (and strong) passwords.
@anon: you should read the comments before posting. Someone already pointed out that this is not an option when using more than one computer. And lots of people do just that.
I also use 1Password... Yeah it doesn't work on other machines, but they're releasing on online version soon that will take care of that. I'm not sure I'll use it, but I don't really need it anyway. So, assuming I stay local to this machine, it's going to remain a better solution than OpenID. (I've landed on a few OpenID sites - I chose not to use it.)
"Sorry! You will not be able to login to this website as it is using an older version of the the OpenID technology. Yahoo! only supports OpenID 2.0 because it is more secure. For more information, check out the OpenID documentation at Yahoo! Developer Network."
The http:// prefix is not required, as per the OpenID spec. This at least makes it look simpler, eg.
My OpenID is thus merely methylblue.com.
The biggest issues in my mind, are the usability one, since users are redirected to a completely different site to log in - this is disorientating. And that there is a single point of failure, if my provider went down for a day, or much worse, forever, I'd be a very unhappy Internet user.
Which is one reason you should always delegate the OpenID through your own, or some other URL I guess.
Why bother with all that rigamorole when there is a perfectly good and elegant solution available for free (or cheap if you use it for a lot of passwords)?
I use a product alled roboform (http://www.roboform.com/) to store all my passwords and as a bonus it also has the following nifty features:
* When you do have to fill out a registration form, it remembers all your info and auto-fills it with one click.
* It will autogenerate and fill in a password so you don't have to make them up for every site.
* It stores the PW list encrypted on your hard drive (or thumb drive) and optionally lets you have a single master password to get access to all your sites. Seems more secure than having your PW list stored out on an HTTP server somewhere.
* A side benefit I discovered as a web developer is that it makes it really quick to test web forms of your app so you don't have to fill them out and re-fill them out over and over during testing.
This little cheapie widget totally changed my life. Despite "admin-itions" against re-using the same credentials, I used to do it just to keep track of it all. Now I have strong passwords even for sites where I could care less if someone hacked my account.
PS: No, I don't work for them. I just like to promote really good software when I see it. I am also a huge fan of BeyondCompare and HyperSnap which both fall in the reasonably priced, extremely useful software category.
The point of openid is not to be secure or to help you to login to all your banks. The point is to save you time registering on 100 tiny little sites which all want you to register. Forums, blog comments, food sites, preferences, etc... things nobody cares to steal from you and you wouldnt care if they are... all require you to register, confirm your email, active, etc. All that pain in the ass is solvable with a single openid.
OpenID has never been positioned as replacement for failed MS passport. It's just an easy way to "autocreate" and account on a site that supports it.
OpenID is bad for mobile users (i can't see me typing those damn long OpenID-Urls with my cell phone) and bad for privacy:
I like it that i have multiple identities all over the web. What I say and do here does not have to be linked to what i say somewhere else.
All the people saying MS Passport/Live is a better, more trustworthy option to OpenID - it only works on MS sites. They used to allow third-party sites to accept Passports, but in like four years, they only had about 50 non-MS sites on board and so canned the idea. In a quarter of that time, OpenID has more than 100 times the number of sites on-board that can consume OpenIDs, and it's growing daily. (okay, not entirely sure about the numbers, but they're probably not far off)
As a web developer, I'm concerned about developer incompetence. I must confess that I don't completely understand how OpenID is supposed to work, but I'm concerned that some naive developer is going to do something incredibly boneheaded and virtually give away my credentials. So, my question is this: how much work does a developer have to go through to support OpenId, and is it easy to screw up? Or does OpenId somehow idiot-proof the process?
Centralized usernames/passwords is a good idea, but I'm not sure why it has to be an ugly URL to use, username or email would be a lot nicer. And isn't this pretty much what Microsoft is trying with their Windows Live ID? Until we get one standard for everything, I can't see this working out really well.
How does this work with maintaining the login information for a user? Most of my sites require security roles which need to be checked on each page. I like to go back to the database on each page load to check these (I normally save session variables with username/passwords and then authenticate on each page)... I don't feel really good about simply setting some field as "Logged On".
I do have about 5 or 6 sites of my own, but this discussion has me thinking I should perhaps try and setup all those site to use the same login.
I still don't understand the desire to translate emails into OpenID url's. Surely to the user it's "What I use to login", it just happens to be currently it's prodominently email or username, but there's no reason that can't change. As has been said before, a lot of people understand the concept of the url to their personal site, be that myspace, facebook, livejournal or whatever and these will hopefully eventually all be usable as an OpenID.
OpenID sounds interesting. You can have your "designer URL" point to OpenID provider (with presumably "ugly" naming) as long as you can host static HTML on the former. This delegation or indirection allows you to switch providers, at the cost of having to consult two servers instead of just the latter one.
From reading the comments, I see you can even be your own OpenID provider (thanks mantrid). I assume then that means if you are paranoid enough to do that, then you must run it on your own hardware, not a shared web hosting service. Is this correct?
The Google App Engine offers this type of functionality. You can use their user base as your own.
So With OpenID you can create your own server, have to type longer URL's and it stores all your ID's in one place ....
... How is this 'secure'? It's simpler maybe (and that's debatable?)
Putting the password for a Forum I go to occasionally anywhere near the details of my on-line banking is madness ....
What happens if the OpenID server is offline?
What happens if you no longer own your OpenID domain?
What happens if you need to change you OpenID?
If you are worried about security:
Put a bootable Linux on a memory stick with kiosk mode browser and you have a secure portable simple system ....
After reading this post and doing some research, I've decided to setup my own OpenID server on my website (asmor.com). Beats the hell out of the other options!
Sigh... Now I'm stuck at the long wait for the DNS info on my new subdomain to propagate...
I think SlashID offers a compromise between the two worlds: you still have to go to a third party (SlashID.com) to get an ID, but it's a simple username and password, unlike OpenID's URLs as identifiers. At the moment, SlashID is a centralized system unlike OpenID, so there are chances of an SPOF, but the SlashID guys say they're working towards a de-centralized system. Sounds good to me.
Open ID as idea is pretty cool but executions leaves to desire. Its just another additional thing to carry/remeber. I'd suggest using something everyone has and what also takes into consideration mobile users: mobile phone and mobile phone number - allmost everyone has it, its constantly carried with.
I use roboform. granted I only use 2-3 computers at most and I keep an encrypted copy of my roboform data on a thumb drive in case I need it someplace else (hasn't happened yet).
Not a perfect solution, but it remembers for me.
Also, if I am on a site that requires a login and I don't want to register for yet another site, I just go to bugmenot.com and find a UID/PWD that will work. Great for loggin in to newspaper and maazine sites that want a (free) account to read stuff.
OpenID is one of those ideas that us geeks really latch onto, but we forget that users aren't geeks. It imposes a change from the status quo, more steps to remember and a potential for capturing their real login info from their OpenID provider if they aren't careful about SSL.
I don't see this as a problem that needs solving. Firefox remembers my logins just fine, I can use my email to recover them if lost and my firefox profile is easily backed up and transferred to other machines.
Why even have passwords? Everyone forgets them all the time anyway and uses the "i forgot my password"-function so just send us the login-link without forcing us through all these steps to recover our password.
Disposable loginlinks sent to your email ftw.
1. Instead of username/password you just fill in your email and click send.
2. Wait 5secs for a mail with a one-time-use login-link, valid for ~10mins, to drop down in your inbox.
3. Click this link and you are now logged in!
This assumes that most users have their email-client running all the time.
Then all you have to remember is your mail-account and mail-password.
How about a fingerprint sensor on my mouse? Then I don't even have to remember my name. Maybe in 10 years...
Why do you need any credentials at all?
The thing I keep missing about OpenID is that it seems to have mechanisms in place to help users trust the provider(s) they choose, but I don't see where web sites can trust the providers that their users are using.
I don't want a hacker to set up an OpenID provider on a zombie server somewhere, and then use logins from that provider to log on to my site and dump spam all over the place, let alone conduct financial transactions. How do I, as someone who'd like to allow OpenID logins on my site, verify that the providers are legitimate?
In my experience, most sites/blogs that support OpenID are using it as an alternative to logins such as the one on this comment page. Seems pointless, since it's just as much work as typing in your name/email.
Are there any major blogs that allow commenting with OpenID in lieu of account creation?
Interesting because stackoverflow.com is a site for advanced computer users. For 90% of the population the "Remember Password" check box in IE or FF takes care of the login issue, but stackoverflow is really for those 10% who consider security when browsing the web.
Still seems like a lot of work for a marginal benefit but I'm curious to see how it works out.
I think a lot of people are missing the point of OpenID, or aren't understanding what it's about.
As a consuming website (a site accepting an OpenID login), you don't have access to the user's credentials aside from (a) their OpenID URI, and (b) whatever is sent via SREG (simple registration) or Attribute Exchange (both of which allow the user to specify, via their OpenID account, what - if any - addition information above and beyond their OpenID URI is sent to the consuming website).
@Fake51: A decent OpenID provider will allow you to pick a STRONG password - randomly generated, 16+ characters long, upper/lower-case characters, numbers, symbols, spaces. Such a password makes it very difficult to "guess" with a dictionary attack.
@anon Wrong - signing up to a new site without OpenID will still require you to key in all the supposed required information in setting up a new account, which will not be stored in Firefox (the inbuilt password manager only stored the username, password, and associated site). Unless you are referring to data stored within Firefox's form cache (which any good person will regularly clear out), then you've missed the mark here.
@Aaron G: Microsoft Passport/Live is a centralised proprietary authentication system owned and run by Microsoft. OpenID is a decentralised system based upon open standards and is not "owned" by any single person or company. Yes, your login details are "centralised" at your OpenID provider, but they are "decentralised" from the consuming websites.
@alphager: You say you don't want to type those, "damn long OpenID-Urls with my cell phone". Say your email address is with Yahoo!. How is typing in email@example.com much different or longer to me.yahoo.com/mynickname (a whole 3 characters longer).
@Clinton Pierce: Whilst you make a point, this is the exact type of behaviour people should be changing. Having 1-4 usernames and 1-4 passwords with one email address is inherently insecure. Generally, email is inherently insecure (unless signed with a PGP/GPG key.. and how often does that happen in the wild?). At least OpenID provides the option of security features that would usually mean an intruder would need to either (a) know the person (eg., to get mobile phone or fob), or (b) have access to their PC (for ID Cards (eg., CardSpace) or client certificates), or (c) both!
@Kris: URL vs email? As I said above, they're not that different (replace '@' with '/').
@Jaster: no banking websites accept OpenD (yet?), probably never will. There is nothing to say that if this changed down that track, that you couldn't run two OpenIDs - one for day to day use, and one for secure mission-critical applications such as banking. Yes, that means two identities - but it's still better than the current 50+ many people have. Even now, many people (certainly OpenID-proficient/keen) have OpenIDs with many providers. These can be tied together (to an extent - if one wishes it to be so).
@Olavi: Nice idea, but almost every site that provides interaction with mobile phones is US/Canada/UK limited - leaving most of the world in the dark. It would require too many contracts with network providers and too much stuffing round to get off the ground. Even established websites can't offer decent worldwide mobile phone interaction with their websites to a user's mobile phone.
@Wayne: bugmenot = FTW!
@bcl: New versions of web browsers are looking at SSL and user "awareness" more carefully. eg., changing the colour of the address bar based upon a good/bad SSL connection/certificate. Regardless, OpenID will always ask a user to accept/reject a login request for a new website. If this is asked on an already accepted/rejected site, then the user should be aware that something is amiss. Likewise, if the user is NOT asked on a new site, they should also be aware. People can't afford to be complacent online - and many people (especially gen y'ers or technically-illiterate-yet-still-remain-online) already are.
The main thing to remember here is - you have choice. You have the ability to choose whichever OpenID provider you want. Check out their features, check out their security measures. Do you trust them? Do they support delegation? If not, move on. I use myOpenID and trust it. Why? It's run by a company of good folk who have a key involvement and investment in the OpenID community, and are responsible for many of the open source libraries available.
It is not clear from this article what the difference is between having an OpenID which is 'trusted' (and only requires a URL to login) and having a website that only requires an e-mail address with no password.
What stops someone guessing your OpenID URL when it is 'trusted' and you no longer have to provide credentials to access a site?
Surely, anyone can guess your OpenID easily enough, at which point non-security-critical websites could bypass the whole process by making passwords optional, thereby making OpenID redundant.
@D. Lambert: You can request additional information when a new user logs into your site the first time using OpenID (or every time really I suppose). Ask them to perform a challenge request (eg., CAPTCHA) at your site after OpenID verification/login.
@Josh Stodola: Then you need to read the "Fingerprint Charade" by Kim Cameron at the Identity Blog - http://www.identityblog.com/?p=981 :)
/shutting up now!
You talk about the complexity of setting up your OpenID provider... but that's a one time cost. The additional overhead once you already have an OpenID provider is practically zero.
If you have your own domain, you can also delegate your OpenID so that I can keep the same OpenID URL (my domain name), but delegate the responsibility to a different provider next week if the one I have this week turns out to suck.
Although I support OpenId as an application developer, my experience as a user has been quite bad so far!
That's why for the moment, I'm all in favour of password managers:
I use 1password on Mac, RoboForms on Windows. I believe they're both largely worth their price. There is also KeePass which is free.
You know, all this talk of OpenID made me want to use one of my OpenID to create a new journal.
So, knowing that LiveJournal supports OpenID, I waltzed over to its sign up page: a href="https://www.livejournal.com/create.bml"https://www.livejournal.com/create.bml/a
See anything missing from that form?
That's right, Livejournal DOESN'T ACCEPT OpenID for journal creation, only for posting comments: a href="http://www.vgmusic.com/~rbemrose/images/screenshots/lj-openid.png"http://www.vgmusic.com/~rbemrose/images/screenshots/lj-openid.png/a
If Livejournal won't eat their own dogfood, as a developer, why should I?
'"the only password you need to remember is your Master Password"
That's until you move to another computer, in which case you're a little screwed (and lot's of people log in on lots of different computers all the time).'
This is ture, but as someone else pointed out, just put Keepass on your thumb drive, that's what I do and the problem is virtually solved, at least between the two or three Windows boxes I log into.
The problem with this approach is that I'm screwed when I login to a Linux or Mac box, which I do quite frequently as well.
What we need is a cross-platform app to run off of a thumb drive that will store usernames and passwords for us.
The security to this approach lies in that fact that YOU have control over your thumb drive, you're not reliant on a third-party's security or lack there of. You're also able to use different usernames and passwords for different sites.
Hmmmmmm, I think its time for me to figure out how best to go about doing this...........
I'd have to say that associating yourself with a strange but relatively short URL is not significantly different than with email. Email *is* a URL - we just don't use the "mailto:" convention because the "@" syntax is unique among URL formats. Adding "http:" is a little extra typing, but the only real difference is that the position of the user identifier and host domain aren't consistent in the definition of OpenID - but they will be consistent for the user, as your openID provide won't likely change much.
Using the URL only seems strange to us because we are so used to using our emails as logins in so many places. I'm willing to bet that if you taught a new user how to use the OpenID format, they would adopt it as quickly as we have adopted any other convention.
My problem: I have multiple OpenID IDs. I had an account with Yahoo, an account with AOL, an account with Livejournal, and so on. So now I have several "single" sign-ons. There's no obvious way to consolidate all of them together into the mystical single sign-on.
Personally, I prefer e-mail address. Because I own my own domain, every site gets a different e-mail address, and I use a catch-all to get them. This makes filtering a lot easier (sent to X@Y.com), helps see who sells my e-mail address (hey, I'm getting spam sent to X@Y.com. I wonder how they got X's name!), and still gives me a rememberable, unique username for each site. Not all sites are as kind about username, though.
This has the typical e-mail-as-gateway problem. Essentially, I'm not sure how you get away from reducing passwords causing points of failure to be more important to secure.
"Perhaps the most compelling point Jan makes is this one: it is a bit odd to ask users to associate themselves with an arbitrary URL instead of an email address"
What's the difference between firstname.lastname@example.org and someprovider.com/yourname or yourname.someprovider besides the order? Both seem equally arbitrary. The only advantage is the standard formatting for e-mail addresses.
This may sound devilishly naive of me, but how is having to remember passwords a problem? Are we really becoming that lazy?
Case: A man stores all his valuable phone number contacts in his cell phone. He loses the phone and the SIM card. He no longer has the ability to contact anyone of import because he never learned those numbers. We now want instantaneous communication with everyone we've ever met, through IM, text messages, emails, message boards, chat lines, et al. But we don't store any of this knowledge. It's just more noise.
If a site requires me to login, and it's something that is ever-so painful for me to do, I just won't create an account. If it's something important to me, then I do. I generate a random password in my PasswordSafe (one I don't even know) and just pop it in there, unless a password is automatically generated by the system. Either way, I store it in my safe, to which only I have the key.
This is a long discussion about a non-problem. There is no login explosion. If you think there is, then you've created too many accounts. Take a break, go outside.
Say it with me: THERE IS NO LOGIN EXPLOSION. Unless there's also a phone number explosion that we, as developers, need to contain. And an email address explosion. And a designer clothes explosion.
Am I the only one that has no problem remembering his login information?
How much work does a developer have to go through to support OpenId, and is it easy to screw up? Or does OpenId somehow idiot-proof the process?
OpenId will generally be far more secure than the average developer implementation of username/password. Assuming you choose a provider that uses SSL.
My problem: I have multiple OpenID IDs.
How is that a problem? You have several different forms of identification in your wallet and house right now. Passport, driver's license, birth certificate, credit cards, etc, etc. All useful in different (and sometimes very narrow) circumstances.
@Jon Raynor, you managed to answer your issues with OpenID with your complaints about passwords. OpenID can solve your password problems; your OpenID provider doesn't need to use passwords if it has some other means of authentication.
Open id is good. In order to remember the url use your own blog url as open id. Use delegation if required.
I've got the impression that most people criticising OpenID here don't really grok the concept. Jeff, perhaps you could write a bit more about it –or simply post a link to the Identity 2.0 talk by Dick Hardt (which admittedly is *not* OpenID but the thrust goes into the same direction). A lot of the complaints here – centralizing credentials, giving away trust or control, etc. are exactly the opposite of what OpenID might establish.
A lot of (if not all) the security concerns people are mentioning are answered by the Simon Willison video linked in the first comment above.
In particular, he points out that emailing a token to the user when they forget their password is exactly equivalent (as far as security) to using OpenID -- in both cases you're trusting your security to a third party that the user trusts.
So if you don't trust a Yahoo OpenID, you shouldn't email a "use this one-time token to login" to any Yahoo email address either.
I find it funny that so many people say "use the same username and password for all your sites!"... Yeah, you could do that for convenience, but that means you trust the owners of each of those sites to not try to use your same username and password on other common sites for their own nefarious purposes.
OpenId is great, it shouldn't replace dedicated logins for things like bank accounts yet, but for the majority of sites out there, it's a great concept.
One way to improve it would be to work on some sort of browser integration with it... Maybe make a Firefox Addon that handles the login a little better and more secure than just counting on the user to verify that they are redirected to their openid site and not a phishing site.
Personally, I prefer info cards over OpenID. However, neither is really ubiquitious.
This is why I use RoboForm password manager. Others in the comments have recommended simmilar. I don't know any of my passwords but a few like my email and my bank. However, there is a portable version of RoboForm, RoboForm2Go which makes this all portable. You just plug your S3 USB key into any PC and roboform is attached to the browser.
There is also an alternative site, https://mashedlife.com/ . This place is similar to OpenID however the places you login to don't need to support OpenId. It is like RoboForm but on the web. So, you don't need your USB key. Of course, you have to trust them since they have all your passwords... but if you can trust an OpenID provider, why not them?
Hmm.. I didn't see anyone mention Password Composer (http://tinyurl.com/bhg3p). The passwords it generates aren't cryptographically strong or anything, but nothing stops you from changing the Greasemonkey script if you need that. I have no idea what my passwords are anymore... and if I need them, I can ask for them to be displayed (click on the "*" while typing the password and it will be revealed in clear).
It also solves ICR's problem: "That's until you move to another computer, in which case you're a little screwed (and lot's of people log in on lots of different computers all the time)."
I just need password composer installed on Firefox on all those computers. It works by combining the master password and domain name... so NO password is stored anywhere.
I have three sets of passwords: one for sites I care nothing about, one for sites I care about, and one for high security sites such as banking, Amazon, and Ebay (and each of these is a little different).
I agree, I hate the process of having to create yet another account. Every single damn BBoard in existence seems to want me to create an account, sometimes even just to view the posts already on there.
I'd love to have a standardized system for logging in, especially across BBoards.
OpenID looks like it's a bit too clunky to work, though. Microsoft Passport, as much as I hate to say it, looks like the better solution.
Does that mean if your favourite site adjusts its domain name, you're kind of screwed?
I second (or rather fifth, sixth, seventh) those who've pointed out KeePass (or its ilk) as a perfectly reasonable, safe, secure option for managing one's passwords. The model's a great one: I own the app, I own the password file (which is itself password-protected -- symbolically analogous to my OpenID url), and it creates excellent, strong passwords for me -- all I have to do is open, find, copy-paste, and I'm golden. It's not one click, but it's rarely more than a few. KeePass, essentially, *is* OpenID, only it's in my pocket, behind my firewall, and physically locked up in my house, rather than floating "out there" in the cloud somewhere, waiting to be compromised.
Identity services like OpenID don't seem to solve much of a problem, then. As users, we already *have* the option of using one username and password for everything. Better we don't, of course -- better (IMO, though it seems pretty obvious) that we keep our identities more, rather than less, fragmented, and hence more secure, if only for there being so many more locks to negotiate.
As such an obvious
I think the point that needs to be driven home here is the one that no-one has mentioned yet: audience. stackoverflow is designed for the tech savvy, and setting up/using a OpenID is not beyond the comprehension of the users.
But it does become 'just another n/p' if that user doesn't already have an OpenID account.