8 ms·

Open ID Is A Nightmare

311 points by chanks 16y ago

Groxx 16y ago
So... the problem is that it's too easy to forget your OpenID / its login. 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.
- robconery 16y ago
  The problem is less that it's easy to forget - it's more that it's easier to completely lose someone. For instance, you forget your login to HN and you can go through a reminder process - pretty simple. You forget your Open ID you're in a world of pain. 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.
  - Groxx 16y ago
    Same as email accounts now; lose one, or it goes under, and you're in a world of pain because those handy "forgot password" links are tied to that. Moreover, most sites can't help you - the emails contain (usually) no information about you as a person. 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.
    - wvenable 16y ago
      > lose one, or it goes under, and you're in a world of pain because those handy "forgot password" links are tied to that. 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.
      - Groxx 16y ago
        No. Lose your email, and you lose your account. Your sign-up email is probably in there, and the new "owners" can go click the "forgot password" link.
        dasil003 16y ago
        You don't need it, if you remember your login and password then you login and change your email. You're not going to sign up with an email that you've lost.
        Groxx 16y ago
        You seem to be under the mistaken assumption that this sort of thing will a) inform you you have lost your email account, and b) will only occur after you've noticed. 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.
- mcantor 16y ago
  http://news.ycombinator.com/item?id=1915686 http://news.ycombinator.com/item?id=1915686 I'm kind of creeped out, honestly.
  - Groxx 16y ago
    lol, awesome. Good to see I'm not totally insane in this, then. 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...)
- tptacek 16y ago
  If you get to stipulate browser support, you can do much more interesting things than OpenID. Not requiring browser support to be viable is part of the point of OpenID and OAuth.
  - mcantor 16y ago
    I think that's what the OP is lamenting: That we've traded one problem (remembering which screen name/e-mail address and password you used to log in) with another one (remembering which OpenID you used to sign up, and dealing with the technical repercussions therein), while there is a seemingly superior solution out there (let the browser(s) handle it).
    - Hkaccc 16y ago
      On the other hand, authenticating users by their browser is like authenticating passengers by the car they're in.
  - Groxx 16y ago
    Where am I "stipulating" browser support? I'm saying it could be easier with browser support. Easy enough to the point where people would prefer it, causing everything to support it instead of the anemic few we have now. 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.
- bad_user 16y ago
  You actually keep your passwords in your browser's password manager? 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.
  - wvenable 16y ago
    Sync your passwords securely to the cloud, single point of failure averted. For maximum security, also set the master password on your browser.
  - epochwolf 16y ago
    Actually no, Groxx and I both use 1Password at this time and sync it's database to dropbox. 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)
- darklajid 16y ago
  That's not serious, is it? 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.
  - Groxx 16y ago
    That's the same situation as we have right now, where their login or their email are identical points of failure. Forget one / lose access to your email, and you lose the ability to get back in, so people make a new account. It's not like having usernames and passwords is preventing this. 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.
    - awj 16y ago
      ... except logins and emails are known, understood points of failure that tend to fail closed. 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.
- Splines 16y ago
  Why stop at the browser? I'd love to see a unified ID that persists who I am from when I log on to the computer, check my email, go to HN, and then play some online games. All of this is technically possible, but it's like herding cats.
- zaphar 16y ago
  I sort of think the problem is that many people have multiple OpenId providers. It sort of reduces half the reason you want to use it. Originally OpenId was a way to have one authentication for multiple services on the net. However when you have a Google Account, A Facebook account, A Twitter account... problems start happening. Which one did you use to login to this service last time? 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?
  - silencio 16y ago
    Yep, this is my problem, not that I actually forgot all the logins to my individual OpenID provider accounts and variants (but when that happens once in a while, that's also a clusterfuck...). I have one for my domain with myOpenID, I have at least one each through google, yahoo, facebook, twitter, livejournal... every site offering those logins uses any combination of all of those, and I can't remember which OpenID I need to use with the site. 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.
  - jerf 16y ago
    "Now I need an OpenId manager in my browser like I needed a password manager before. How is this better?" 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" /> with appropriate values. 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.
- mivok 16y ago
  Actually, it seems to me the bigger problem is that some providers just decide to change who they say you are, and those providers (Google) just happen to be the biggest because you're telling users 'just use your google login here'. They don't know anything about openID. Sure, users having multiple OpenIDs is an issue when they forget which they used, but even if this was solved, the other issue seems to be much worse.
  - Groxx 16y ago
    A provider changing their URL: totally agree, huge problem. But that's on the same scale as your email provider changing their URL. Problematic and rare. And it's something nothing can adequately deal with - your "forgot password" links won't work if your email changes domain names. It's also an abnormality that can't be securely accounted for, because otherwise MITMs could just hijack requests and send it to their own servers with no complaints.
- thwarted 16y ago
  If we're all going to use SSL to avoid attacks that Firesheep brought to the forefront, users can provide client certificates to different websites, managed on a per-user basis with a passphrase like pass managers work.
  - caf 16y ago
    The problem with client certificates is that they reside in just one of your browsers - what happens when you want to log in from your girlfriend's PC? 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.
    - thwarted 16y ago
      That same issue exists with a password manager, especially one that exists in the browser. Which is why I suggested client certs need to be managed in some portable manner. Since browsers have started using OS services for certificate management, the portability may be easier. 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.
- joe_the_user 16y ago
  A) I think you read the first third of the article. The second part goes into the meat of the problem (multiple implementations, providers not being consistent etc). B) Having a browser store everything isn't necessarily a great solution since people may use multiple browsers and public terminals.
- cahit 16y ago
  Forgetting ID/Password is not the only problem with OpenId. The real problem I see is that, you're not only authenticated with your H/Y/GMail user name, but that you have to be authenticated on their servers and open a valid session there without you being aware that it's not closed after you login to the target OpenId site. You still have that open session even if you log out of the target site (or a go-between like ClickPass). For OpenID to work as designed, the user should not have multiple ones and always use the same one wherever an OpenID is requested.
- bdonlan 16y ago
  If we're going to push OpenID support into the browser, then why not just use the X.509 client certificate support that's already available?
- Qz 16y ago
  Mozilla was working on that exact thing for Firefox 4 but it got postponed to a later release...
mcantor 16y ago
I'm really surprised that this hasn't been solved by browser vendors yet. 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.
- wvenable 16y ago
  If you want to involve browser makers, why not eliminate the OpenID providers entirely? If I can store my profile in my browser and allow/deny sending my information on site-by-site basis we wouldn't need OpenID at all. And there are already plenty of services to sync your browser information (logins, bookmarks, history) to the cloud.
  - seanalltogether 16y ago
    Chrome should start doing this immediately, since they're one of the few browser vendors that can easily tie a bunch of these services together.
- Raphael 16y ago
  Browsers store cookies that allow you to stay signed in.
terra_t 16y ago
This is why I'm likely to use Facebook Connect. Sure, some people hate Facebook (maybe I lose 20% of sign-ups) but giving people 30 million choices causes them to freeze up (lose 80% of sign-ups)
- moxiemk1 16y ago
  Is that all you're going to allow? I know I'm in the vast minority, but when sites only allow Facebook Connect, I don't use them. (still haven't made a Quora account). Maybe a small link underneath "Use other identity providers..." for those of us who wont do it?
  - ElbertF 16y ago
    I'm not on Facebook and have a Quora account, is this a new requirement (I probably signed up during the betas)?
    - moxiemk1 16y ago
      You're correct, I just checked. At one point, I remember there only being "Connect with Facebook" on the quora.com page for signing up. Now, both Twitter and Email are options. I guess I'll check this thing out now
- nkohari 16y ago
  Or you could lose 0% of signups by asking for a username and password. (Well, okay, there might be a small margin of people who refuse to sign up -- but if they're that picky, you probably don't want them as your customers anyway.)
  - albertzeyer 16y ago
    If it is some random site I am visiting where I have not been before, I will much more likely login via Facebook Connect or OpenID than going through some registering (where I usually have to figure out what types of passwords it accepts, about a free username, and wait for an accept mail and all that through a terribly annoying and slow guidance).
deleted 16y ago
[deleted]
mivok 16y ago
It seems to me that the problem of multiple OpenID providers and people not knowing which one they're using would be a lot less serious if all of these companies that are OpenID providers actually accepted logins via OpenID themselves instead of everyone paying lip service to the idea while trying to be the one source of identity for everyone else. That way you could be using the same ID for twitter/google/facebook etc. and when it says 'use your google/twitter credentials to log in' then there is only one set of credentials to use.
xiongchiamiov 16y ago
Of course, if people didn't have accounts with 10 different OpenID providers in the first place, they wouldn't have to remember which one they used. It seems like many big sites opted to become a provider rather than start accepting logins from existing providers, for which I suppose I can't blame them.
- mivok 16y ago
  Why not blame the bigger sites? If they accepted logins from other OpenID providers, then people would have a lot fewer possibilities to remember. I honestly believe this is a big part of the problem with OpenID adoption currently.
  - xentronium 16y ago
    The problem is that bigger sites don't want to depend on other openid providers.
ancymon 16y ago
In my opinion author should first read OpenID specifications and implement some "best practices" (http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Practices http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Pr...). Doing so might have solve his "problems". I think to make user "NOT to feel stupid" it's better to implement OpenID properly than quit it. 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.
- robconery 16y ago
  It's a fair point - the problem is that if I'm going to ask for a user/password for a master account then... WTF do I need OpenID for? Also - in terms of reading the spec - we use JanRain/RPX so I let them worry about that.
michaelchisari 16y ago
This is one of the reasons your Open ID should have been formed like an email address, ie, username@domain.ext 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.
- jomohke 16y ago
  OpenId does have this in the form of a URL as your identifier. If you had a myopenid.com account, for example, you can login to your site using 'michaelchisari.myopenid.com'. That page will contain a metadata tag specifying who your provider is (You could use any domain/page you control as long as you add a metadata tag to it). 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.
  - michaelchisari 16y ago
    True, however, michaelchisari.myopenid.com is not the same as michaelchisari@myopenid.com, though, which I firmly believe if OpenID had standardized on, what was lost in flexibility, would have been more than made up through user adoption.
    - jomohke 16y ago
      Agreed. Though it would only work if email providers also became OpenID providers (which admittedly would have been very possible), or else having two things that look just like email addresses could cause similar confusion. 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 http://news.ycombinator.com/item?id=1916033
joedaltonwallas 16y ago
Why people are so frightend of storing the salt & hash of the user password? May be I am mistaken but if the salt is unique for each hash it is almost imposible to recover the original password. Of course you must use a well proven encription library but it is trivial. Am I missing something?
- adambyrtek 16y ago
  Who is frightened of that? The problem discussed here is with managing logins information for different sites, not hashing on the server side.
  - joedaltonwallas 16y ago
    He talks about it as a nightmare wich implies that storing emails/hashes is worse. 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.
- moshezadka 16y ago
  Yes, you are missing one thing: if you are storing that file, a security breach (several kinds of those) means an attacker can get that file. Are you thinking this is not a problem? Think again! * 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.
djacobs 16y ago
This is the problem i-names are intended to solve. 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) Et cetera. 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.
- nkohari 16y ago
  How is this in any demonstrable way better than a username and password? I can't even imagine trying to explain how to use this to my parents.
  - djacobs 16y ago
    Your mother doesn't need to understand it. I gave the technical details because this is Hacker News. Brokers need to make setup simpler, yes. But even today, logging in is as simple as typing =djacobs.
    - nkohari 16y ago
sams99 16y ago
I agree, open id sucks. Or more specifically the billion different evolving implementations of open id suck. Making your users feels stupid sucks and having your business totally dependent on a third party sucks. 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.
jrockway 16y ago
The problem with OpenID is that everyone wants to be a provider, but nobody wants to let me use it to log in. This means everyone has 10 different OpenIDs, but only one place to log into. Very stupid.
- david927 16y ago
  Not so much stupid as greedy. The user base is the juice. It's the most important thing most big sites have, and farming that out to another provider is giving it to them. No one wants to do that. Facebook is hardly going to say, "Login with your Twitter account." 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.
  - rbanffy 16y ago
    > Facebook is hardly going to say, "Login with your Twitter account." Not really. The value for Facebook is in the data stored on Facebook's computers. Who provides credentials is not that important.
  - InclinedPlane 16y ago
    Why? 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).
steven_h 16y ago
I think that this isn't really a problem if you remember that your users will forget which Open ID they used and if you allow them to use all their Open IDs, bad things will happen. 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.
deleted 16y ago
[deleted]
patio11 16y ago
Having implemented it for a day job, there is no power on earth or under it which can force me to ever put it in one of my products. OpenID doesn't really have a handle on the problem it is solving and almost certainly pessimizes for the metrics I most care about, like conversion rates, success with signup/signin, customer support costs, and mental wellbeing among the engineering team (i.e. me).
mechanical_fish 16y ago
Seems like as good a time as any to ask, yet again: Will I ever be able to use a simple username and password to log into a Stack Exchange site? Please?
gibsonf1 16y ago
We've set up openid+oauth with Google Apps Marketplace, and the solution there is very elegant. Users from their google apps gmail interface can select an app from "more" and get automatically logged in to our web app. (using extended cl-openid for google app domains and cl-oauth)
mike463 16y ago
As a user, I HATE openid. 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.
indiejade 16y ago
The spirit of the OpenID concept is a good one, though. I'm one of the people who attended the first OpenID dev camp (before OpenID was adopted on a wide scale) http://openid.net/2008/01/14/the-first-openiddevcamp-was-a-success/ http://openid.net/2008/01/14/the-first-openiddevcamp-was-a-s... and there was (and arguably still is) a need for something like it. 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.
nikcub 16y ago
Great post - but yet another example of a blog without a sidebar or header. When I got to the point where you started talking about your own company I scrolled up and down to find a blurb about it. You introduced your company name assuming we know who they are and what they do. 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 :)

311 points by chanks 16y ago

Groxx 16y ago

So... the problem is that it's too easy to forget your OpenID / its login. 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.

robconery 16y ago
The problem is less that it's easy to forget - it's more that it's easier to completely lose someone. For instance, you forget your login to HN and you can go through a reminder process - pretty simple. You forget your Open ID you're in a world of pain. 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.
- Groxx 16y ago
  Same as email accounts now; lose one, or it goes under, and you're in a world of pain because those handy "forgot password" links are tied to that. Moreover, most sites can't help you - the emails contain (usually) no information about you as a person. 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.
  - wvenable 16y ago
    > lose one, or it goes under, and you're in a world of pain because those handy "forgot password" links are tied to that. 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.
    - Groxx 16y ago
      No. Lose your email, and you lose your account. Your sign-up email is probably in there, and the new "owners" can go click the "forgot password" link.
      - dasil003 16y ago
        You don't need it, if you remember your login and password then you login and change your email. You're not going to sign up with an email that you've lost.
        Groxx 16y ago
        You seem to be under the mistaken assumption that this sort of thing will a) inform you you have lost your email account, and b) will only occur after you've noticed. 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.
mcantor 16y ago
http://news.ycombinator.com/item?id=1915686 http://news.ycombinator.com/item?id=1915686 I'm kind of creeped out, honestly.
- Groxx 16y ago
  lol, awesome. Good to see I'm not totally insane in this, then. 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...)
tptacek 16y ago
If you get to stipulate browser support, you can do much more interesting things than OpenID. Not requiring browser support to be viable is part of the point of OpenID and OAuth.
- mcantor 16y ago
  I think that's what the OP is lamenting: That we've traded one problem (remembering which screen name/e-mail address and password you used to log in) with another one (remembering which OpenID you used to sign up, and dealing with the technical repercussions therein), while there is a seemingly superior solution out there (let the browser(s) handle it).
  - Hkaccc 16y ago
    On the other hand, authenticating users by their browser is like authenticating passengers by the car they're in.
- Groxx 16y ago
  Where am I "stipulating" browser support? I'm saying it could be easier with browser support. Easy enough to the point where people would prefer it, causing everything to support it instead of the anemic few we have now. 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.
bad_user 16y ago
You actually keep your passwords in your browser's password manager? 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.
- wvenable 16y ago
  Sync your passwords securely to the cloud, single point of failure averted. For maximum security, also set the master password on your browser.
- epochwolf 16y ago
  Actually no, Groxx and I both use 1Password at this time and sync it's database to dropbox. 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)
darklajid 16y ago
That's not serious, is it? 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.
- Groxx 16y ago
  That's the same situation as we have right now, where their login or their email are identical points of failure. Forget one / lose access to your email, and you lose the ability to get back in, so people make a new account. It's not like having usernames and passwords is preventing this. 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.
  - awj 16y ago
    ... except logins and emails are known, understood points of failure that tend to fail closed. 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.
Splines 16y ago
Why stop at the browser? I'd love to see a unified ID that persists who I am from when I log on to the computer, check my email, go to HN, and then play some online games. All of this is technically possible, but it's like herding cats.
zaphar 16y ago
I sort of think the problem is that many people have multiple OpenId providers. It sort of reduces half the reason you want to use it. Originally OpenId was a way to have one authentication for multiple services on the net. However when you have a Google Account, A Facebook account, A Twitter account... problems start happening. Which one did you use to login to this service last time? 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?
- silencio 16y ago
  Yep, this is my problem, not that I actually forgot all the logins to my individual OpenID provider accounts and variants (but when that happens once in a while, that's also a clusterfuck...). I have one for my domain with myOpenID, I have at least one each through google, yahoo, facebook, twitter, livejournal... every site offering those logins uses any combination of all of those, and I can't remember which OpenID I need to use with the site. 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.
- jerf 16y ago
  "Now I need an OpenId manager in my browser like I needed a password manager before. How is this better?" 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" /> with appropriate values. 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.
mivok 16y ago
Actually, it seems to me the bigger problem is that some providers just decide to change who they say you are, and those providers (Google) just happen to be the biggest because you're telling users 'just use your google login here'. They don't know anything about openID. Sure, users having multiple OpenIDs is an issue when they forget which they used, but even if this was solved, the other issue seems to be much worse.
- Groxx 16y ago
  A provider changing their URL: totally agree, huge problem. But that's on the same scale as your email provider changing their URL. Problematic and rare. And it's something nothing can adequately deal with - your "forgot password" links won't work if your email changes domain names. It's also an abnormality that can't be securely accounted for, because otherwise MITMs could just hijack requests and send it to their own servers with no complaints.
thwarted 16y ago
If we're all going to use SSL to avoid attacks that Firesheep brought to the forefront, users can provide client certificates to different websites, managed on a per-user basis with a passphrase like pass managers work.
- caf 16y ago
  The problem with client certificates is that they reside in just one of your browsers - what happens when you want to log in from your girlfriend's PC? 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.
  - thwarted 16y ago
    That same issue exists with a password manager, especially one that exists in the browser. Which is why I suggested client certs need to be managed in some portable manner. Since browsers have started using OS services for certificate management, the portability may be easier. 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.
joe_the_user 16y ago
A) I think you read the first third of the article. The second part goes into the meat of the problem (multiple implementations, providers not being consistent etc). B) Having a browser store everything isn't necessarily a great solution since people may use multiple browsers and public terminals.
cahit 16y ago
Forgetting ID/Password is not the only problem with OpenId. The real problem I see is that, you're not only authenticated with your H/Y/GMail user name, but that you have to be authenticated on their servers and open a valid session there without you being aware that it's not closed after you login to the target OpenId site. You still have that open session even if you log out of the target site (or a go-between like ClickPass). For OpenID to work as designed, the user should not have multiple ones and always use the same one wherever an OpenID is requested.
bdonlan 16y ago
If we're going to push OpenID support into the browser, then why not just use the X.509 client certificate support that's already available?
Qz 16y ago
Mozilla was working on that exact thing for Firefox 4 but it got postponed to a later release...

mcantor 16y ago

I'm really surprised that this hasn't been solved by browser vendors yet. 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.

wvenable 16y ago
If you want to involve browser makers, why not eliminate the OpenID providers entirely? If I can store my profile in my browser and allow/deny sending my information on site-by-site basis we wouldn't need OpenID at all. And there are already plenty of services to sync your browser information (logins, bookmarks, history) to the cloud.
- seanalltogether 16y ago
  Chrome should start doing this immediately, since they're one of the few browser vendors that can easily tie a bunch of these services together.
Raphael 16y ago
Browsers store cookies that allow you to stay signed in.

terra_t 16y ago

This is why I'm likely to use Facebook Connect. Sure, some people hate Facebook (maybe I lose 20% of sign-ups) but giving people 30 million choices causes them to freeze up (lose 80% of sign-ups)

moxiemk1 16y ago
Is that all you're going to allow? I know I'm in the vast minority, but when sites only allow Facebook Connect, I don't use them. (still haven't made a Quora account). Maybe a small link underneath "Use other identity providers..." for those of us who wont do it?
- ElbertF 16y ago
  I'm not on Facebook and have a Quora account, is this a new requirement (I probably signed up during the betas)?
  - moxiemk1 16y ago
    You're correct, I just checked. At one point, I remember there only being "Connect with Facebook" on the quora.com page for signing up. Now, both Twitter and Email are options. I guess I'll check this thing out now
nkohari 16y ago
Or you could lose 0% of signups by asking for a username and password. (Well, okay, there might be a small margin of people who refuse to sign up -- but if they're that picky, you probably don't want them as your customers anyway.)
- albertzeyer 16y ago
  If it is some random site I am visiting where I have not been before, I will much more likely login via Facebook Connect or OpenID than going through some registering (where I usually have to figure out what types of passwords it accepts, about a free username, and wait for an accept mail and all that through a terribly annoying and slow guidance).

deleted 16y ago

[deleted]

mivok 16y ago

It seems to me that the problem of multiple OpenID providers and people not knowing which one they're using would be a lot less serious if all of these companies that are OpenID providers actually accepted logins via OpenID themselves instead of everyone paying lip service to the idea while trying to be the one source of identity for everyone else. That way you could be using the same ID for twitter/google/facebook etc. and when it says 'use your google/twitter credentials to log in' then there is only one set of credentials to use.

xiongchiamiov 16y ago

Of course, if people didn't have accounts with 10 different OpenID providers in the first place, they wouldn't have to remember which one they used. It seems like many big sites opted to become a provider rather than start accepting logins from existing providers, for which I suppose I can't blame them.

mivok 16y ago
Why not blame the bigger sites? If they accepted logins from other OpenID providers, then people would have a lot fewer possibilities to remember. I honestly believe this is a big part of the problem with OpenID adoption currently.
- xentronium 16y ago
  The problem is that bigger sites don't want to depend on other openid providers.

ancymon 16y ago

In my opinion author should first read OpenID specifications and implement some "best practices" (http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Practices http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Pr...). Doing so might have solve his "problems". I think to make user "NOT to feel stupid" it's better to implement OpenID properly than quit it. 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.

robconery 16y ago
It's a fair point - the problem is that if I'm going to ask for a user/password for a master account then... WTF do I need OpenID for? Also - in terms of reading the spec - we use JanRain/RPX so I let them worry about that.

michaelchisari 16y ago

This is one of the reasons your Open ID should have been formed like an email address, ie, username@domain.ext 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.

jomohke 16y ago
OpenId does have this in the form of a URL as your identifier. If you had a myopenid.com account, for example, you can login to your site using 'michaelchisari.myopenid.com'. That page will contain a metadata tag specifying who your provider is (You could use any domain/page you control as long as you add a metadata tag to it). 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.
- michaelchisari 16y ago
  True, however, michaelchisari.myopenid.com is not the same as michaelchisari@myopenid.com, though, which I firmly believe if OpenID had standardized on, what was lost in flexibility, would have been more than made up through user adoption.
  - jomohke 16y ago
    Agreed. Though it would only work if email providers also became OpenID providers (which admittedly would have been very possible), or else having two things that look just like email addresses could cause similar confusion. 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 http://news.ycombinator.com/item?id=1916033

joedaltonwallas 16y ago

Why people are so frightend of storing the salt & hash of the user password? May be I am mistaken but if the salt is unique for each hash it is almost imposible to recover the original password. Of course you must use a well proven encription library but it is trivial. Am I missing something?

adambyrtek 16y ago
Who is frightened of that? The problem discussed here is with managing logins information for different sites, not hashing on the server side.
- joedaltonwallas 16y ago
  He talks about it as a nightmare wich implies that storing emails/hashes is worse. 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.
moshezadka 16y ago
Yes, you are missing one thing: if you are storing that file, a security breach (several kinds of those) means an attacker can get that file. Are you thinking this is not a problem? Think again! * 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.

djacobs 16y ago

This is the problem i-names are intended to solve. 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) Et cetera. 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.

nkohari 16y ago
How is this in any demonstrable way better than a username and password? I can't even imagine trying to explain how to use this to my parents.
- djacobs 16y ago
  Your mother doesn't need to understand it. I gave the technical details because this is Hacker News. Brokers need to make setup simpler, yes. But even today, logging in is as simple as typing =djacobs.
  - nkohari 16y ago

sams99 16y ago

I agree, open id sucks. Or more specifically the billion different evolving implementations of open id suck. Making your users feels stupid sucks and having your business totally dependent on a third party sucks. 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.

jrockway 16y ago

The problem with OpenID is that everyone wants to be a provider, but nobody wants to let me use it to log in. This means everyone has 10 different OpenIDs, but only one place to log into. Very stupid.

david927 16y ago
Not so much stupid as greedy. The user base is the juice. It's the most important thing most big sites have, and farming that out to another provider is giving it to them. No one wants to do that. Facebook is hardly going to say, "Login with your Twitter account." 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.
- rbanffy 16y ago
  > Facebook is hardly going to say, "Login with your Twitter account." Not really. The value for Facebook is in the data stored on Facebook's computers. Who provides credentials is not that important.
- InclinedPlane 16y ago
  Why? 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).

steven_h 16y ago

I think that this isn't really a problem if you remember that your users will forget which Open ID they used and if you allow them to use all their Open IDs, bad things will happen. 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.

deleted 16y ago

[deleted]

patio11 16y ago

Having implemented it for a day job, there is no power on earth or under it which can force me to ever put it in one of my products. OpenID doesn't really have a handle on the problem it is solving and almost certainly pessimizes for the metrics I most care about, like conversion rates, success with signup/signin, customer support costs, and mental wellbeing among the engineering team (i.e. me).

mechanical_fish 16y ago

Seems like as good a time as any to ask, yet again: Will I ever be able to use a simple username and password to log into a Stack Exchange site? Please?

gibsonf1 16y ago

We've set up openid+oauth with Google Apps Marketplace, and the solution there is very elegant. Users from their google apps gmail interface can select an app from "more" and get automatically logged in to our web app. (using extended cl-openid for google app domains and cl-oauth)

mike463 16y ago

As a user, I HATE openid. 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.

indiejade 16y ago

The spirit of the OpenID concept is a good one, though. I'm one of the people who attended the first OpenID dev camp (before OpenID was adopted on a wide scale) http://openid.net/2008/01/14/the-first-openiddevcamp-was-a-success/ http://openid.net/2008/01/14/the-first-openiddevcamp-was-a-s... and there was (and arguably still is) a need for something like it. 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.

nikcub 16y ago

Great post - but yet another example of a blog without a sidebar or header. When I got to the point where you started talking about your own company I scrolled up and down to find a blurb about it. You introduced your company name assuming we know who they are and what they do. 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 :)