Open ID Is A Nightmare
blog.wekeroad.com
blog.wekeroad.com
I propose that the main reason for this is because browsers (and password-storing applications in general) have practically zero support for OpenID. It's all handled by hand. It's all in your head, and nowhere else.
Sorta reminds me of, oh... browsers before password managers. Far far more people used only a couple username/password combinations, or stored their ones in a text file somewhere. Now that managers are integrated, and secure external ones exist, it's viable to actually be safer with your logins, and many more people do so. And now I rely so heavily on my password manager, I only know a couple key points-of-entry where its data is stored - the rest of my passwords are all randomly generated.
OpenID is essentially the next step, and it's precisely the same end-user problem. Imagine if browsers supported it natively via a profile-like system; pick a profile, and every site you've associated with it is immediately logged in for you. You'd be able to handle multiple people using your computer easily - just enter a password to use that profile, and everything can be switched for you. No need to launch that password manager for every site, you sign in once and everything is automatically connected from that point.
OpenID can be significantly more user-friendly than username + password. It just isn't there yet.
Moreover most sites can't help you - the URLs contain (usually) no information about you as a person. So you come to me and say "I don't know my login" or worse: "My Open ID provider is gone".
All I can do is shrug. The it becomes a matter of sleuthing: IP addresses, PayPal transactions (if you use them)... and so on.
I agree it can be better - but it's technology that when mixed with users is a nightmare.
All of which is only solved by alternate means of identification. ie, GMail lets you specify a cell phone, many other sites have pseudo-personal questions you have to guess to perform a reset without a password / email, etc. What reason is there that a site can't ask a series of questions to re-point an account to a new OpenID?
None of this is any different. At all. The only difference is in managing one OpenID vs widely varying logins on every site on the internet.
That requires two failures: you forgot your username/password and you lost your email account. That's not the same as forgetting your OpenID or having the provider go down. If you've got username/password, then email is the alternative means of identification. One of the main points of OpenID is avoid giving alternative means of identification, such as an email address.
Give me your email account. I can nearly guarantee you I can have 5 sites with new passwords inside 5 minutes. And that's by hand - anyone serious about this could write a couple scripts to grab dozens of the major sites in seconds.
I'm kind of creeped out, honestly.
I honestly fail to see any reason OpenID, precisely as it is now, cannot be significantly easier to use than username + password, and more secure because people can deal with a single, better password. It's harder on websites, granted... but in terms of security, most have been slacking pretty hard as-is. (though that's all the more reason to take it out of their hands...)
This is one of those areas where people improving security frequently seem to fail to comprehend human behavior. For OpenID to gain critical mass, the average person has to be able to use it simply and correctly enough that they will make the switch. And that implies incredible simplicity. OpenID has the capability, but it seems implementers go out of their way to make the process anything but simple, so people get confused and leave for a lock-in solution like Facebook that has a single button to press.
You get people to improve their habits by being easier than their old habits, not by telling them their old habits are dangerous and look, here's a better option. If that worked, people wouldn't be drinking and smoking so much.
That's a single point of failure btw.
It is actually a lot better to spread your accounts in a couple of buckets (work, personal, sensitive, junk) and remember just those.
I also have the daily backups turned on in case of database corruption. With dropbox and my backups I have the file in 4 locations at any one time (work laptop, personal laptop, home server, and backup disk)
The real point is, that you cannot be sure that you can identify _your customers_. The providers change, you greet them with "Hey, welcome. What do you want to buy here?" instead of saying "Hey, Groxx. Glad you are back. Feel free to use X, Y and Z that you gave us money for in the past".
I really like OpenID, but insights like this seriously scare me. And they are _not_ customer friendly when they _don't_ work. Understand that you have no control over that "when" though - you rely on someone else to allow your paying customers to use your (purchased) service.
As to providers changing, that's where you allow multiple OpenIDs per person, as fallbacks / alternate ways of signing in. So long as they control one, they can control all. It's not OpenID's fault few sites do this, it's the epic adherence to preferring username + password columns in databases instead of a separate table which would allow for more than one.
If I forget my login I can't access the website, but I can usually go to the website and play email bingo until I hit the one I used.
If my email access goes down, I still can't access the website, but I know why and have bigger problems.
If I log in with the wrong openid provider ... provider bingo is the ideal case. Otherwise I get in but it looks like my stuff on the website I'm logging into got wiped out. Obviously to most people here it would look more like they used the wrong provider, but that only qualifies openid as a solution for techies.
That's a much more serious customer problem from an end-user standpoint. Telling people they can register multiple providers with their account is a band-aid on a bullet wound.
And that's just when things are working as intended. Idiot providers, bad implementations, openid servers going down, all of these things add even more potential to screw things up for you.
What? No. Only if the site presumes a brand-new OpenID means a brand-new account, and automatically creates it for you. And it'll probably be asking you for a username and email - at which point it likely will throw a database constraint, telling you you can't use that username or email. And the vast majority I've encountered ask you if you want to create an account under that OpenID.
And this is also no different than, say, Instapaper, where just entering an email / username offers to create a new one. It could easily do so automatically. What if you forgot you had one under a different email? You're just conflating human forgetfulness and poor website design with inherent problems of OpenID which don't really exist.
A fair number of sites allow you to register multiple emails. Is this not a band-aid to the bullet wound which email accounts are?
On the flip side, we have idiot websites storing passwords in clear-text, or hashed without salting, all of which means if they get hacked they get thousands of accounts, likely thousands of email accounts as well (as many / enough use the same password). With OpenID, they'll just get your public OpenID URL - whoop-de-doo.
In fact, I'd say that the (rarely used) adequate security measures to protect your password are band-aids on the bad implementation that is username-and-password.
I understand password pain, but so does everyone else. The song and dance is annoying, but known. I'd rather spend the time dealing with an explosion of openid misimplementations adding useful features that don't carry a risk of pissing off my users.
Like... email addresses? Or do you not think it's good to provide a "forgot password" link which emails a reset mechanism?
Any other means of re-gaining access, like "secret questions", work for both lost email accounts and OpenID, and any site which asks for an email address to mail "forgot"-like requests to has all the capabilities of any system which has an email address.
So your complaint is that OpenID providers aren't mature enough to be reliable enough to last long enough to be worthwhile. Providers like Google, Verisign, Yahoo, and many others of the internet / security / email giants.
If they've made stupid decisions in the past, that's an entirely different problem. Email providers can and do and have made plenty of stupid decisions - one of mine only allows login via plain-text username and password over POP. Two of my older ones went belly-up. One got purchased, and transitioned everyone over to a new domain name as they phased out the old one. How is this different?
Yeah, but those are for retrieving an account, not for day-to-day logins. I'm only dealing with trouble when someone's email provider goes down and they can't remember their password. With openid I'm in trouble when the provider goes down period.
> So your complaint is that OpenID providers aren't mature enough to be reliable enough to last long enough to be worthwhile. Providers like Google, Verisign, Yahoo, and many others of the internet / security / email giants.
Being big giants doesn't make them awesome at everything they attempt. Half of this article was griping about Google changing tokens and provider urls.
Also, with openid I don't get to pick who I trust to do their job correctly. At the least I shouldn't, if I'm implementing it properly. Maybe if I could I would decide that Google, Verisign and Yahoo can do it well, but I'd rather not depend on MomAndPopsIDShop to hold it together. I don't really get that choice, and instead my user experience is up to them holding up their end of the deal.
> Email providers can and do and have made plenty of stupid decisions - one of mine only allows login via plain-text username and password over POP.
This applies equally to openid. A dumb implementation can be just about as insecure.
> Two of my older ones went belly-up. One got purchased, and transitioned everyone over to a new domain name as they phased out the old one. How is this different?
Well, for starters it's a known problem. Also you know the token I'm using to uniquely identify your account, it's the same email that's now become a problem. But if tomorrow your provider decides that, instead of "5AHGFOA12389E" you are "ABNA489AKJ12" ... we're both kind of stuck. You only know your openid, and I only really know the token that just changed. Sure I can ask for even more information from you, but there's a limit on how many hoops I'm willing to jump through before admitting that openid is a bad business decision.
That's probably where we're disagreeing. This is precisely why I like OpenID: it takes logins out of your / site owners' hands, where it's always been, and where it's been abused to no end, and puts it in mine, where I can actually make a few decisions.
I'm not really sure what the solution here is, because as a developer I would like to see openid work. Right now it's just hard to argue for.
As to the customer service issues, if they're having a problem on your site, they're having a problem on every site if they're using OpenID, because their ID has changed everywhere. It's far easier to diagnose the problem there, as it lies wholly (and provably) with their provider, and not with you.
More of a headache for you, potentially, people are nuts when they don't get what they want. But at least you have a provable "out" and they have a single place to go for a solution (if there can be one).
It's also about not having to trust the site owner to not misuse your password or release it or get hacked, which has happened before (though not to me). Loads of people use the same password on their email as they do on website-X, however stupid that may be. This is essentially giving website-X access to your entire identity, as nearly everything is keyed around your email account. Identity theft, here we come; already a tens-of-billions-of-dollars industry in USA alone.
Instead, you choose who you want to trust with that information. Your OpenID provider. And you restrict your logins to 1, instead of N, making it far simpler to use a more secure login for even the most computer-inept.
Actually, with the username+password I'm always the provider. I can give whatever information I want.
I don't disagree with what you say about website and identity -- but I think OpenID is the wrong solution to the problem. This should be embedded into the browser with strong cryptography between you and the website and no 3rd party should ever need to be involved. If I want to invent a new throw-away identity, it should be a simple click away.
Being secure with a username+password is pretty much as easy or as difficult as using OpenID. If the goal is to secure the computer-inept, requiring them to associate a url with their identity is a failure even before you get through the rest of the process.
All of this is technically possible, but it's like herding cats.
Part of the problem I think is that the providers don't act as consumers also. If I originally had an open id somewhere then why can't I use it for facebook, Google, Twitter, and whatever else. Each "Provider" that offers a service to me which I want forces me to get yet another OpenId. At this point I think I have rougly 4 different OpenId providers and with Google I have like 4 different id's. This gets unwieldy quick. The technology had promise but the way it was rolled out and adopted by various folks caused it to suck a little.
Now I need an OpenId manager in my browser like I needed a password manager before. How is this better?
This is why I can't even remember the last time I posted on Stack Overflow. I once had to email Jeff Atwood because I had managed to create two accounts with two different identities (this was long ago, before you were able to associate multiple OpenID identities to a single user), and to this day I still don't remember which ones work with the user that has the highest reputation. So I don't even bother logging in most of the time, and choose a random login every time I do.
OpenID's biggest end-user benefit was supposed to cut down on the number of disparate accounts people tend to have across multiple websites, and it became moot when everyone and their mother decided that they needed to be the be-all end-all of OpenID providers by turning your login details and identity with that website into an OpenID or OpenID type identity.
What you really need is delegation. In a webpage, place in the <head>:
<link rel="openid.server" href="openID server URL" />
<link rel="openid.delegate" href="openID server" />
My OpenID is "http://jerf.org". I delegate that to AOL right now, but I can change that to any provider transparently. (The ickiness of using AOL is mitigated by the trivial way in which I can change it; which of the corporate monstrosities auths me isn't very important, and of the various accounts I have they were the first to be a provider.)
Having this implemented by your metaphorical grandmother is obviously a problem.
Edit: And also, I'd observe that this solves your personal OpenID problem. It doesn't do a thing to solve the problem for a site trying to use OpenID, such as the original article author, because telling everyone to delegate like this is a boil-the-ocean solution in the context of cutting down support calls.
there are two problems with OpenID.
#1 the UX has been killed by committee more than once. ( i should know I worked on it. )
#2 OpenID does not offer value for one, let alone many OpenIDs.
Password managers make some bets on input fields that use the password type to manage login pairs, but I think we need to take this further.
I think we need to start having browsers connect cookies and openid redirect flows to login pairs. I think we can observe openid login flows in the browser and... remember them! I think we can link that to a browser profile, and I think we can pair that to a cookie set. I think smart-identity-browsers can suggest OpenIDs and make OpenID NASCAR obsolete, or at-least auto create a popular field of buttons, rather than making that site specific.
This is probably not enough space to discuss in detail how I think the tech can mature. but i think it's obvious that the future of the web is mobile, and is identity based. these interfaces don't need to get a little bit simpler, they need to get a lot simpler. they need to work on mobile phones.
a lot of the work i have done on OpenID comes to naught when you try to copy that experience for mobile phones.
When I give my open ID to a site (usually blogger.com to make a comment), I actually type in "jerf.org" after the http:// , with nothing else. I do not have a provider set up, which I looked into but is a pain in the bum, and, as it turns out, entirely unnecessary. Instead, the OpenID consumer hits the page I gave (my domain's front page, as it turns out), finds those tags, redirects to "whatever those tags say today", and then I log in that way. When I have successfully logged in with the delegated service, then I have successfully authenticated myself as "http://jerf.org". I say "whatever those tags say today" because if I change those tags on that page to delegate to Google, suddenly I can log in with Google, but I will still be authenticated as "http://jerf.org". If AOL, my current delegate, decides to get out of the OpenID business entirely, one minute with vim on my website allows me to move it somewhere else, again, all along, I'm "http://jerf.org". This layer of indirection solved all the problems I had with the idea.
I don't have "many" OpenIDs, the phrase of yours that led me to wonder if you (and perhaps others) aren't following me here. I have one: http://jerf.org. Of course like everybody else I can't even count the number of accounts I have with various OpenID providers, but I don't care; http://jerf.org is my OpenID, and will be until I no longer have the domain.
I also don't know why it would "appeal" to one of the crowds you listed, but not others. The crowd it "appeals" to is the crowd that has control over a website that includes the ability to set arbitrary tags into the heading of a webpage, rather than a pre-canned HTML template that can't be touched. Unfortunately, rather fewer people have websites with that amount of control than I'd like.
This is precisely my problem. I don't want to commit to maintaining a webpage at a given domain with a given set of headers for the rest of my life.
Imagine if OpenID had been designed in 1991. Perhaps it would have been called "GopherID". And I might still have my GopherID from 1991, provided I had kept up the Gopher server that was delegating it, and could find another (trustworthy!) person on this Earth who would bother to operate a reliable GopherID server eighteen years after it mattered.
You see the problem? The web is barely old enough to vote. Any identity that ties me to some web standard of 2010 is as ephemeral as the morning dew, eight-track tapes, and the Commodore 64 floppy disk.
Meanwhile, I just visited Slashdot for the first time in years. My user ID is only three digits, but my login still works. It's a username and a password, it's built out of text, the protocol is obvious, and it's going to work as long as Slashdot works.
This would be true as well if you'd use OpenID. OpenID dies when HTTP web services die, but then Slashdot will die, too.
I doubt that. "http://jerf.org is a string that you type into the OpenID box ("endpoint URL"?), not the ID itself. I use Google Apps and set my site up using an X-XRDS-Location header so I can type in "http://id.example.com into the box, but the identity the site gets is something like "http://example.com/openid?id=123456789. This identity will probably change if I switch to using AOL.
So unless I screwed up, it is possible for it to work the way I describe, and it is possible for it to work the way you describe, depending. I'm calmed back down, but in general that's pretty worthless. I can not imagine why it should not always work the way I describe, it's the entire bloody point. Providers shouldn't even be able to screw me over that way.
The catch, however, is that many providers screw the identity up. For example I set up a page at http://foo.com with necessary headers to delegate to my Google Account. Using the OpenID support on App Engine, I get the federated identity as http://foo.com/openid?id=[SOME RANDOM DIGITS] instead.
The idea of OpenID and delegation is awesome. In reality the millions different implementations fked up the whole thing, not even to mention the control and reliability issues.
Have I mentioned recently that implementing OpenID is a source of endless amusement?
That is itself a problem. Sites and advertisers don't even need sneaky cookie tricks to track you across all the sites you use: you're doing it for them. I really don't want one single identity token for every site on the Internet.
Believe me, I'm not claiming OpenID is teh awesome. I'm just saying that certain criticisms can be mitigated if you are in control of a web page. As claims go, this isn't very strong.
the problem is that so many people want simple these days. in the beginning the internet was for geeks. today the internet needs to be for everyone.
my really smart friends in social games, always get frustrated, because they can never create a game that is fun for them. rather they need to create games for the masses. many of us still enjoy the complexity of supreme commander or civ5, but instead design things like mobsters and farm-ville because that is what people ( on average ) can handle.
OpenID has been designed by way to many smart people for their own needs and does not often times take the simple shortcut. there are people from government institutions at these committee meetings trying to leverage OpenID into a government ready spec.
the OpenID groups should really segment along a few different paths and focus on unique consumer segments like social, fiscal, and real identity.
the other problem is that RP ( relying parties ) otherwise known as the 3rd party site don't like OpenIDs because there is not a guaranteed messaging protocol for communication between end users and the OpenID. RPs have been asking for email address as part of the registration process, and OpenID providers always stand on the legs of privacy when asked for this, but the reality is that relieving email address leaves Providers vulnerable as their motives for OpenID are around engagement numbers.
There are political challenges to overcome with OpenID before it can move forwards. I think that is why Facebook is walking over everyone here. They don't have to deal with those issues.
Nobody at OpenId seems to have quite thought through the incentives here. Identification is not in fact a technical problem. That's trivial. It's a business/social problem.
The problem is, "How can I make multi-billion dollar companies want to outsource identification to someone else, given that they're reasonably bright and given that every time in the past that someone else has inserted themselves into another's business, things have gone badly for the insertee?"
Businesses look at situations where companies like Ticketmaster and OpenTable have successfully inserted themselves between pre-existing businesses and their customers, and siphoned off a lot of the value of those customers. Then they say, "Gee, maybe I should learn from that and not let someone do that to me." And then the OpenID geeks come calling saying they've got a great solution where all you have to do is outsource your accounts to another multi-billion dollar company and everything will be cool, that other company TOTALLY won't steal your business or anything.
You need some method of authorising yourself at new locations, presumably rooted in a username/password somewhere, and you need the UI for that to be dead simple.
The logging in from your girlfriend's PC is a valid use case, but that's the price you pay for not having to remember passwords. Alternatively, you have an account on your girlfriend's PC that has your certificate store in it.
I don't envision the UI for this being any different than for a password manager. In fact, you don't even need more than one certificate, the same cert can be given to every website. Self-signed certs could be used as long as the website only allows login with a single certificate, the server could cache the certificate information as part of the "account" information and only ever allow a single certificate, in the same way ssh keys work (if ssh keys are secure enough is beyond the scope of this discussion). Or for the use-your-girlfriend's-pc scenario, you can bind multiple certificates, stored on different computers, with your account. Account recovery, in the event you need to change the certificate you use, would work just like password recovery, you assert you can't login, the site emails you a link to a page where you can tell it about your new certificate. This is no more or less secure than account recovery with passwords (where access to the email account is proof enough that you are who you are), but the main goal here is to assert to the website your authentication so you don't need to remember different passwords all over the place.
I don't think we have a "dead simple" key/cert generation/store right now that would make this work for Joe User, but I think the backend technology is already there.
The problem is essentially that moving your certificate store around is not a task that Joe User can accomplish, because the UI sucks. (Oh, and I also agree that this problem also exists for browser-based password stores).
Build a better interface, and it might just work. For example, I should be able to roll up to a new browser, login to some "home site" (whether run by Apple, Google, Firefox or whoever) and use my single username/password to download a client certificate, that then authorises me to login to my accounts on Twitter, Facebook and so on. Ideally, I could request a time-limited temporary certificate, so that it becomes useless after I've gone.
B) Having a browser store everything isn't necessarily a great solution since people may use multiple browsers and public terminals.
For OpenID to work as designed, the user should not have multiple ones and always use the same one wherever an OpenID is requested.
It was a nice idea, but the successor (and there will be a successor to OpenID) will be more flexible and the sole provider. It's the only way it can work.
Not really. The value for Facebook is in the data stored on Facebook's computers. Who provides credentials is not that important.
What's so special about a username + password combination vs. an openid?
Users, of facebook for example, will still provide facebook with their name, their phone number, their email address, their birthday, etc. Not to mention the torrent of information from photos, friends lists, likes, and posts. Consider that any site offering password recovery to an email address already effectively delegates user identity and verification to another site (the email provider).
That way, sites can immediately tell the domain name of the provider, and the user to verify, without having the extra selection step for the user. It's also more familiar to users.
This is one of the reasons I decided to not go with OpenID as primary identity authentication for Appleseed.
This is the default way that OpenID works -- The selection of providers is purely a UI choice that has become popular by sites to hide users from URLs.
There's always still a box near the bottom that allows you to type in your URL without picking a provider.
An advantage of URLs is that you have the choice of whether to give your email address to the site. Myopenid.com will prompt you for whatever information the site requests, and you can even choose which email address (if any) to provide the site. Sites which use an email address for login currently require you to remember which spam email address you gave them.
The indirection offered by URLs is quite powerful too: See jerf's comment: http://news.ycombinator.com/item?id=1916033
I use one unique username/password for each site I visit. My browser will maintain this for the sites I'd like it to, and sites where security is important, I type it in manually.
In my opinion, developers are being selfish. They want one of their coding problems to go away (authentication and all it entails), at the expense of their users.
With openid, I have to open two accounts. One on the site, and another separate openid account to provide authentication. Problems? Well, it could be one, or the other. Does the brower help me? NO. Does it make me feel more secure? NO.
I used to contribute to stackoverflow, and then after having to deal with openid all those times, I STOPPED USING THE SITE.
There is a lot of suck.
However, to balance things out, remembering 100 different passwords sucks. Getting an email to 100 different users on 100 different MXs, without being flagged as spam, sucks. Recovering an account when a primary email address stops working, cause a user switched jobs, sucks. Having to change your password every time you visit a site (cause you visit it twice a year), sucks. I know: keypass, self hosted clipperz, passpack. They are all at best awkward.
So, at the end of the day, you are stuck making a decision that is sucky, no matter what you choose.
When I built community tracker, I decided unique logins and valid emails are a valid requirement, openid is a nice add-on. A year later hacks have been added to the open-id code.. It is code I hate touching, with conditional edge cases, and is super hard to test. I decided against RPX cause I dislike the idea of adding one more business dependency. It just felt wrong. Honestly, I am not convinced the headache was worth it. Users love to be able to click on the google button and get access to the site.
When I am working on Stack Overflow, occasionally, I wish we had the "unique valid email" and "unique login" requirements. The whole cookie based account thing we have scares me (Jeff says it is what makes us better than all those sites that use slimy tricks to get your email).
However, it is far from our biggest problem. It is very easy to create an account, you can even answer a question without logging on using open id. The amount of customer service emails we get with regards to merging accounts is manageable. The majority of users, use the google button, and the google button works. The merging / recovery process and overhead is annoying but, not out-of-control annoying.
There are tweaks, we probably should not be rendering that scary URL Google gives us. We should look at ways to cut down on support calls.
Overall, I agree, for a business that is selling stuff to its users, making openid the only way for your customers to buy stuff may not a good idea.
However, for a business, that is trying to make the Internet a better place, the dependency on openid and all the hacks that come with it, is tolerable. And doing a little bit to stop users from adding, yet another password, to the never ending pool of passwords has its appeal.
Will I ever be able to use a simple username and password to log into a Stack Exchange site?
Please?
You should be able to tell your browser about your OpenID account(s), so it can keep you logged in constantly. "Hey! Your OpenID login has expired. Please login again now, or hit 'Later' to see this prompt the next time you try to access an account."
Then, when you go to a website that supports OpenID, your browser can tell it, "Hey. Don't bother presenting us with a login prompt. Just check to see if you have any accounts associated with these OpenIDs."
Of course, it can't be that simplistic, because the site needs to verify authentication with your provider, not your potentially devious browser. But I feel like that is not a difficult problem to solve.
It's one-and-a-half steps. The first "half" step is "Logging in," because you only have to do it once per browser session. The first real step is: "Go to the site." Done.
When I implemented Open ID the last time I used their OpenID identifier and then had their e-mail tied to that account, you had to have an e-mail so if your OpenID didn't supply an e-mail then the web app asked for one. If you tried to log in with a different OpenID and used the same e-mail, it would tell you that you already have an account.
This doesn't solve the problem 100% but it helps, you just have to design your applications assuming that you wil be the smartest person to use your application.
Maybe a small link underneath "Use other identity providers..." for those of us who wont do it?
I guess I'll check this thing out now
(i) people take their Facebook identities seriously, so they're less likely to be griefers, and (ii) the like mechanism to push back updates about items that have changed
An i-name is a short name that looks something like =name. So instead of your OpenId URL, you can type in =name in any OpenId form and it will log you in as usual.
So instead of name.myopenid.com, I'm =name.
There are registrars who sell an i-names for relatively cheap. (There are also free ones.) The i-name points to the broker's lookup service. In their database, your i-name is associated with a unique number that you keep even if you let your name expire.
That entry points to an XRDS document, and that document tells the login form a number of things. Most importantly, it tells it your OpenId URL. It also provides a series of forwarding addresses that look like this:
=djacobs/(+blog)
=djacobs/(+contact)
=djacobs/(+twitter)
My favorite is =djacobs/(+contact). It points to a page on my broker's site with a contact form. This contact form knows my e-mail address, and people can use it to e-mail me without finding that address out--like any other contact form. More importantly, the form comes with useful spam-fighting settings, options like "don't let anyone e-mail me without an i-name of their own".
I happen to think i-names are pretty cool and will tend to make everyone settle on one ID. Maybe a good vocabulary will come out of the forwarding syntax, and we can approach a loose Semantic Web using i-names instead of URLs and triples.
Caveat: As of now this is painfully tedious to set up for the average user. Eventually, though, people will see the merit in this approach, and more competition in this market will drive a user-friendly setup.
For now, it's just for hackers.
Or, you could allow your provider to put a persistent cookie on your machine, and (as we've seen from the Firesheep news lately) making it that much more likely your identity will be compromised. (Not to mention if someone steals the cookie for your OpenID provider, the impact is potentially much larger.)
The i-name stuff is just DNS for OpenID providers. It adds another layer of bullshit on top of layers of bullshit that don't need to be there in the first place.
I carry the key to my car. When I want to get in, I press the button on the fob or I open the door with the key. OpenID is like having to make a phone call to someone, tell them I need to get into my car, so they can then press a button that will open my car door. And hopefully they aren't on their lunchbreak.
Security issues are not unique to i-names, and I think the abstraction layer (removing a domain name from your login) is important and useful.
Disagree if you must.
I think that storing them is not more difficult, it is more convenient and secure (of course this is relative). But maybe I am missing something about the security of this scheme.
* For "moderately" strong passwords (say, ones which need 10,000 attempts to get), getting at your encrypted files means the difference between you being able to throttle-and-disable a serial guesser and having the password hacked (bonus points if that was the password your user uses on other sites with the same usernames.) * An attacker can go over the file to find "extremely" easy password for some user. * A determined attacker can test hundreds of millions of passwords for a specific user, and know when he succeeded, before you ever notice it. So unless your website has a "change password every year" policy, the attacker can breach even "moderately strong" passwords.
This is even before issues like "well proven encryption libraries" are still broken, and if the one you used is broken, your file is still out there.
This doesn't mean that it cannot be done, with enough care -- but it does mean that if you avoid doing it, it's a big relief, and a big potential crisis averted.
In my database I store hashes obtained with Blowfish:
http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-stro...
How many tries would you have to do to guess it? And for the other passwords you have to start all over again.
The main problem is that it complicated things when it originally set out to simplify them. Power users are hesitant to consolidate all their user names and passwords into the ultimate master key; from a security standpoint, better to use separation of control when users are also smart enough to use different names/passwords across a variety of sites.
This happens far too often, help us out by adding a box in the sidebar something simple like:
Hi my name is name. I am the position of company, a what we do service that was launched whenever. To find out more about us, visit our homepage or signup here
Even better, include a mugshot so we know who is talking to us. People like faces, it's comforting :)
1. The OpenID specification suggests that user should be able to associate multiple identifiers with one account. That way if you store user's email address, he can easily add new OpenID account even after he lost/forgot his identifier.
2. You can't expect that OpenID provider has enabled extensions which give away user email. User can also decide not to provide his e-mail. If that's not provided you can ask user to fill a registration form "manually".
And by the way, I think that remembering who is your OpenID provider is still easier than remembering login and password.
Also - in terms of reading the spec - we use JanRain/RPX so I let them worry about that.