Slashdot Mirror
OpenID Fan Club Is Shrinking
A.B. VerHausen writes "Even though there's a whole new Web site devoted to understanding and using OpenID, some companies are dropping the login method altogether. OStatic is reporting that the 'free Web site network Wetpaint announced recently that it will no longer support OpenID as a login option for its wiki, citing low usage and high support costs as reasons.' Apparently, fewer than 200 registered users bothered with OpenID, and the extra QA and development time doesn't make it worthwhile to support. This can't come as welcome news on top of the internal issues the article mentions the OpenID Foundation is having now, too." I've actually been quite happy with OpenID, since I have spawned far too many username/password pairs over the last 20-plus years, but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ...
Rather than trust an external site with all my security, I use a tool called 1Password for Macintosh (there is a similar tool for windows) that secures my passwords in once place and protects them with a single master password. No OpenID required, just the Mac Keychain.
Currently hooked on AMP
I would have beat you if I could have remembered my login details...
Invaders must die
Stack overflow took an interesting approach, and only uses OpenID. They don't even have a non-OpenID option. Proprietor Jeff Atwood discusses some of the tradeoff at his blog.
It would help if the players actually had spent any effort to make it work. Try using Verisign's site and it is horrible. It times out when validating. The others while rich in graphics are no better, nothing to see here .....
"If the King's English was good enough for Jesus, it's good enough for me!" -- "Ma" Ferguson, Governor of Texas (circa
I remember when this came out. I thought to myself "I'll sign up when I run into a website that needs it." Except for this article, that was the last I'd ever heard of it. I'm amazed it is still around.
I read the internet for the articles.
"I've actually been quite happy with OpenID, since I have spawned far too many username/password pairs over the last 20-plus years" What's wrong with Administrator/admin everywhere? In fact, it works so great that entire Windows networks are known to use it. No problems reported so far.
You mean intersection set.
I am not a user so YMMV, but I personally don't like all my eggs in one basket. I use different logins and passwords on most of the sites I visit. I hardly want a security breach on some forum I post to to be able to have access to my email or credit cards site. Centralized is great for some things, but I simply don't trust any company to be as tight with their security as I am with my own. To them a breach is a "whoops, sorry!" to me it could be personally and financially devastating.
Hmmmm...
I checked out the "Explaining OpenID" web site referenced in the article, and it didn't make a whole lot of sense.
It did tell me that my OpenID is: www.google.com/o8/id
I undoubtedly will not remember that, nor do I believe it is even accurate.
I then read how I could integrate it into my own web site - and despite doing a ton of web development and XML stuff, had no idea what they were talking about - at either a high or low level.
In conclusion - If they want to get users and developers on board with OpenID - their going to have to do a hell of a better job. Either that, I'm just too stupid to understand their "OpenID for Dummies" web site.
Now I'm of course just an engineer and developer - I'm sure users like my parents, grandparents and kids would understand this stuff much better.
What is OpenID? Why do I need it? Why should I care?
I think I've only heard vague mention of OpenID on a few websites, with no explanation of what it does.
Do you see OpenID anywhere on the front page to Facebook?
There's your problem, people don't know that OpenID even exists.
Why make things complicated? Just use X.509.
Just have GETs to "http://anyserver.com/id/Lord Ender" return a certificate (public key) issued to, literally "http://anyserver.com/id/Lord Ender".
I would then have the certificate/keypair installed in my browser. It doesn't matter who it is signed by-it can be self-signed.
When I sign in to a website, I put "http://anyserver.com/id/Lord Ender" as my ID. The website then fetches my certificate from anyserver.com and asks my browser to prove I'm me using the built-in features of SSL. From then on, the web site will know me as "Lord Ender of anyserver.com".
It doesn't get any simpler or easier to implement.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
everyone wants to be an openid provider, but no one wants to actually implement it for their site.
where's my slashdot openid login box?
where's my openid option for flickr? hm?
and besides that, what's my openid anyway? openid.aol.com/whatever?
the bar should be set a bit higher for providers and a bit lower for sites and users.
[...] but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ...
*FWEEEEEET*
Penalty on the offense: Illegal use of mixed metaphors. Five yard penalty, repeat second down.
It might also have to do with the fact, that OpenID was never supposed to be a general login system. At its bones, it's a homepage/URL verification protocol for the blogging community. And it's constrained to that, because URLs (no matter how shortened) are not *common*-user-friendly.
but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ...
If it's a chicken-and-egg problem, wouldn't it be better to build a chicken trap, with egg catcher?
I am a web developer by trade, and so far one of the most infuriating things that I have to deal with on a weekly basis is that my customers simply can't bring themselves to care enough to remember their admin logins. Every week I have to unlock a handful of administrators. It doesn't matter if I provided them with a proper password rescue option, it is simply too much for them.
The second big problem is that we have multiple branches of certain products running at the same time, so at any given time one of my customers may have to login into her production, staging or 2-3 development servers, each with its own username and password.
We are a .net shop, so my original idea was to use the new membership and role providers and remove the login mechanism from all sites from a given customer. This works, but it is hard to get all sites in line since there is always something else going on that is more important. They still screw it up, but at least they only have to remember one username and password that works at the same level (production, staging, dev, etc.).
When I heard about OpenID I tried to see if I could implement it in any of our sites that use .net 2.0-style security. I was glad to see that somebody already had thought of this, and I found a ready to run library with a very nice login control for .net that uses OpenID.
It wasn't easy, but it was interesting, and within 10 or so hours invested I had:
1. A .net web app that used ANY OpenID instead of the built-in aspnet_* tables hierarchy. .net app that uses the SQL membership/role providers.
2. A recovery page. You type your email address and it emails you a list of any OpenIDs in the system that match that email address.
3. A self-registration page. If you arrive at the web app, and you authenticate through OpenID successfully, and you don't have a local profile, it asks you to fill a quick form.
4. Security roles are used just like any standard
The beauty of it is that I can even run my own OpenID server for my customers. All they would need to remember is that they login by typing a URL like:
userid.ouropenidserver.com
and it would do the rest for them.
One customer, three projects, three environments per project, that's nine login/password pairs that I am expecting them to remember. Instead all they need to remember is the URL and the password. If they lock themselves out, all they need to remember is the email address used to register, which emails them their OpenID URL. If they forget their password, that is handled at the OpenID provider level, not at the end user application.
Even if nobody else in the world uses it, to me it clearly means that I can spend more of my customer's money in building new things instead of on troubleshooting and damage control (even if the two figures are identical, customers will bitch more about paying for repairs than paying for work that can be recognized as new). And it is an easy concept, if they have a Google or AOL account, they already have an OpenID.
Pedro
----
The Insomniac Coder
I'm surprised that /. geeks actually use specific tools to manage their passwords, when it's so much simpler and quicker with a couple of shell micro-scripts.
I have my passwords in a file on a TrueCrypt volume.
In Windows, I have
p.bat: /N /I "%1"
@FIND
and padd.bat:
@ECHO %* >> T:\p
In bash it's almost the same:
p: /mnt/tc/p
#!/bin/sh
grep -in "$1"
and padd.bat: /mnt/tc/p
#!/bin/sh
echo "$@" >>
All I have to do to find all my gmail accounts and passwords is to type "p gmail" at a command prompt.
In Windows (maybe in Linux as well?), you can also play with "Alternate Data Streams"
I don't really like OpenID. I have a lot of email accounts that are separate for a reason. It annoys me when I go to a random site, and one of them is pre-entered into a login box.
I use KeePass to manage usernames/passwords. Having a single ID/password isn't any more convenient.
Authentication on the web is kind of messy and annoying, but OpenID is so too. It just doesn't feel right to be pushed from one server to the next to do authentication, since it leaves the door wide open to phising attacks. Also using URL for authentication just looks ugly.
I personally would prefer something that works on the client side and not on some other third server, i.e. store a GPG public key in your browser and have the browser use that to automatically sign blogposts or whatever to authenticate you. To stop spam one could have third parties sign the GPG key to create a web of trust kind of thing.
So you would have a reusable secure token you use for authentication on all pages, instead of having to come up with new passwords all the time. And it would also keep the third party out of the picture, since the token remains only on your client and never leaves it.
...then you've probably already figured out another solution. Looking at the OpenID Explained site, I see a bunch of explanation of why it's useful. "You choose how much web sites get to see about you." I already have a solution to this. If it's a site I don't trust, I use a disposable Yahoo email account. "Won't bother you for the same information over and over again." Not a big deal. I have about 100 username-password pairs in an encrypted file. This is how many I've collected over roughly a decade. Entering my name and address, etc., an average of ten times a year is not a big deal to me. "You only have to remember one username and one password." Not a big deal. That's why I have the encrypted password file. To use the encrypted password file, I only have to remember one password. "Now, you might already use one username and one password online, but OpenID lets you do this in a secure way. That's because you only give your password to your OpenID provider." Anyone who uses the same username and password for every online account (including important ones like banking, etc.) is extremely naive, and isn't the kind of person who will have heard of OpenID. "Whenever someone sees your OpenID in use, anywhere on the Internet, they'll know that it's you." To me, this seems like a bug, not a feature. It's a single point of failure. E.g., recently I had some trouble with my Amazon account. (Their software was convinced that I had an mp3 file I needed to download, and it kept insisting on trying to make me download it, failing every time.) I called their tech support, and got someone in India who either didn't understand what I was saying or didn't know how to help me. No big deal. I just munged the password on that Amazon account and created a new one. There are lots of other reasons you might want to start over fresh with a different identity on a certain site, e.g., you're being harassed by some other user. But with OpenID, starting over fresh would eliminate the supposed advantage of the system. You'd either have to start over fresh with your entire OpenID setup (meaning you need to get a new account on every site), or you'd have to create a second, special-purpose OpenID (which is contrary to the one-ID-to-rule-them-all raison d'etre of OpenID).
Find free books.
You store your passwords unencrypted?
All the solutions mentioned at least use a symmetric key cipher to encrypt them...
Better mousetrap is named InfoCard. It is based on open WS protocols, it is planned to be inetroperable, it preserves six laws of identity established by Ken Cameron, it works on IE, FireFox and Safari on Windows, OS X and Linux platforms. Sun SSO project, Eclipse Higgins and WSO2 have interoperable open source implementations.
It can be used from browser and for service authorization. It preserves privacy, prevents phishing and is easy to understand through the "Card" metaphor.
The only problem: it was developed inside Microsoft, so people have a knee-jerk refusal reaction to it.
Truth be told, the only way Open ID will gain traction is if someone like google takes it over or implements it (merges it) with google accounts. Something many people have already signed up for. This is what google did with other services they had going.
Personally I use disposable email sites like mailinator.com and Roboform to just register once, then save the password. Then all you do is have to click a button and you can backup your passwords and never have to worry about forgetting a password again.
http://www.roboform.com/
I use a truecrypt volume in autofs which automounts the truecrypt volume when I try to open the password file, and unmounts it two minutes later.
On my site http://crowdnews.eu/ 100% of the sign ups
is by openid.
But thats becouse it is the only option.
If openid is the only options for login
it does simplify the database structure for your site. But the code become more complex.
Also there are some bugs in the openid 2.0 specs. which makes it unsafe and costly.
Also I feel that openid is missing support for online shopping.
I have often felt that the should be easier way to supply all the info they ask, when you buy something online. Also postal address is usely formatted different depending of the region you live in. It would be nice if openid just had a field called postal_address which containd it in a correct user supplied format.
If the openid consortium could make openid 3.0
which made online shopping easier and maybe included a technology like http://ripple.sourceforge.net/
without the bugs in 2.0 then I think it would have a good purpose.
You mean intersection set.
I bet the rugby & Venn diagram intersection set is a small one.
AOL has had this for years. If you have an AOL ID you can see if at http://my.screenname.aol.com./ It's essentially "kerberos for the web". Unfortunately (a) it's a bear to get working (on the apache side), (b) is only used by their partners, and (c) forces you to use your AOL login. But other than that it's pretty nifty - if only they would open source it.
Unless the attacker deletes the recovery emails before you get to them, you'd notice somebody requesting a bunch of password resets. Ditto for signup requests.
With open-id, if you have RMS's Magic URL, you can pretty much go hog-wild as him without ever being noticed. Anything that takes an Open ID URL is something you can sign up for and probably do your bidding un-noticed.
I call bullshit. The person who submitted this article cites a single web site that has dropped OpenID support and then proclaims the conclusion that "OpenID Fan Club is Shrinking." Sorry, but I won't believe that OpenID is dying unless Netcraft confirms it :)
Seriously though, OpenID is doing fine. They could stand to have some better marketing, though. I think that nearly everyone would use OpenID if they only knew it existed.
Tired of FB/Google censorship? Visit UNCENSORED!
That is half the problem. It isn't an intuitive way of logging into a website. Since the days of timeshare computers, people understand "username / password". Nobody understands "URL => ????".
If you were to ask me to write the OpenID obituary, the biggest reason the protocol failed was the decision to use a URL instead of an email address. Every other failure was secondary to that one.
Is it would have allowed a service to easily migrate it's existing userbase to OpenID.
1) Legacy user logs in.
2) System has their email on file and checks to see if that email address now supports OpenID.
3) If the email address now supports OpenID, the website can offer to migrate the user to OpenID.
The big "flaw" in my idea is if the user already exists in the system, why the hell would you want to migrate them to OpenID anyway? Why not just let them use the email address for a login and authenticate locally? Once you migrate them, the user would have to do more steps to log in then before.
Effort was never the issue. The issues are:
a) Selfishness. Too many sites allow you to use their database to log into others, but not use others to log into theirs. Seems the big players want to be the ones owning your data, just like MS tried to own logins with its system... whatever that was called.
b) What does OpenID actually gain you? You still have to enter login details. It's just a URL instead of a username. Others have said this above too, but what's needed is something like a wallet: infocard or a keyring manager, which keeps track of all your details on your machine, and extends your single desktop sign-on to websites, so you don't need to log in at all. Most of this tech is available and implemented, with firefox's password memory, and desktops' wallets. Unfortunately, again, people are competing to control this, instead of focusing on an open system. An open, Infocard system for GNOME/KDE and other desktops (all equally supported and native), which presents web logins as "Here's your wallet. Select which ID card you want this site to use" would nail this problem easily.
I didn't see this explained on that web page. Why should my web site use OpenID?
As a user of websites, I also see this as a big problem. How do I get all those various username/password pairs I already have on a few hundred websites tied into OpenID? I do not want to give up the names I have. And to complicate things a bit more, I have more than one on a few of them. How is that handled? And what happens with I visit a new website somewhere and want to be known as Skapare there, too?
It seems to me that this would all be better done in the client browser, using a standardized means of logging in (which must also always be done via HTTPS). A standardized collection of all your logins for all the websites you visit would be stored in an encrypted file (which you can configure to be anywhere you want it to be on your host system or network shared filespace). When you visit a site that needs a login and you have a login on that site, the web browser will show you the logins you have there (after you have entered the passphrase to open you credentials data file) and allow you to pick one. Then it does the login exchange via a special URL accessed via HTTPS and gets the time limited login hash back from that. When the time runs out on that hash, it repeats this process invisibly (except maybe a little flag somewhere showing it is redoing it). A browser button would exist to re-access the logins for the current site allowing you to switch user or log out. A special code from the web site could also log you out (so the website can make a button to logout from within its visible pages). That code could be a URL like "logout://slashdot.org/" or similar (the mere act of trying to access it engages the logout procedure which operates via HTTPS to actually do the logout) which would be used via a link or a Javascript reload.
The protocol on this needs to be standardized thoroughly, and vetted by security experts. Then it needs to be made entirely open and free for everyone to use. And it needs to be kept simple (e.g. use the minimum of software so it can be implemented on even the smallest systems in the smallest clients).
now we need to go OSS in diesel cars
The Magic URL (which is magic, actually) *IS THE USERNAME AND PASSWORD*. That is the whole point of OpenID. A website leaves the username/password business to some other guy and just trusts the protocol to make sure the Magic-URL is legit.
If you've hacked RMS's OpenID account, you can just go to any OpenID site, even if he never visited it before, and start impersonating him. That is the "benefit" of OpenID! Most of the OpenID authenticated sites out there dont have a concept of "sign up", you just go to the site, plug in your Magic URL and start doing shit. There is no email confirmation step on those site, and if there was, it would kinda defeat the whole purpose of OpenID in the first place.
And if I'm wrong in my interpretation of this, please send me to a URL that actually explains how the damn thing works. Nobody gets it and if the OpenID guys can't explain it clearly, they probably dont get it either.
Lets say I've hacked your OpenID account. Now I can go visit sites like StackOverflow and post as you. Since they dont require email verification when you "sign-up", it doesn't matter if you had an existing account with them before I hacked you. I can go anywere that takes OpenID and "silently" impersonate you regardless of if you used the website before. No email verification means you'd probably never know it either. Well.. until you google "AvitarX" and find yourself posting horse porn on some OpenID site.
Facebook doesn't support OpenID.
No one here is pointing out one of the giant, glaring flaws in OpenID: users don't know URLs. Most people understand "www.something.com", and they understand clicking links. They do not understand how that crazy computer speak which comes after ".com/" works, nor do they understand that they can "own" a certain bit of such code.
In other words, "Joe Sixpack" is not going to understand that he is:
http://blogger.google.com/openId/joeSixpack
He would have understood perfectly fine if the OpenID creators had had the sense to base the system of email addresses. Joe Sixpack knows that he's:
joesixpack@gmail.com
already. In fact, on several of the websites Joe uses, he already has to use his email address as his username.
But the OpenID idjits decided for some arcane reason to use the obfuscated URL-based "usernames" rather than the usability standard of email-based ones. And they're somehow surprised at it's spectacular failure (despite a DESPERATE need for a unified authentication system) because ...?
He said, "I have my passwords in a file on a TrueCrypt volume."
His passwords are encrypted on disk.
First of all, please understand I'm going under the assumption I've compromised RMS's OpenID account. This means I can log in using his OpenID provider....
I couldn't use RMS's email address, as it would leave a digital papertrail. Even if I compromised his email, he'd notice the registration emails. I'd have to delete them quicker then he could pull them off the server (esp if POP3 is checking it).
If I made a real ass of myself, the site owner would probably figure out I wasn't actually RMS since I didn't use his email address.
OpenID however has that nifty magic URL business (and yes, it is actually magic, if it wasn't magic we'd all be using it already). His Magic URL is *HIM*, that is the whole point of OpenID. Your existence is tied to a single Magic URL.
Any site that lets me "sign up" using an OpenID URL is fair game. I can go to a site like StackOverflow and use his OpenID and ask silly questions about using Emacs in Vista. Since StackOverflow doesn't confirm my account via email, RMS would never know I was using his account on sites he has never visited himself.
See what I'm saying? Once I compromise an OpenID account, I can go anywhere and post as that account holder. Since most (all?) OpenID authenticated sites don't require email confirmation, odds are very good the holder of the OpenID account would never know I was using their account, doing nefarious things.
Of course, I imagine there are OpenID providers that show a history of sites that you've used your MagicURL to log into. That would probably curb what I'm talking about.
So I went to sign up for Toodledo the other day. On the suggestion of my boss, I went to sign in via OpenID. Well I didn't have an OpenID, so I signed up for one of those through the OpenID provider that Toodledo linked from their very page - myopenid.com. Fair enough. Went back to sign in with Toodledo and my shiny new OpenID and I get an error message back saying "There was an error connecting to your OpenID server."
Well what the hell. I sign up using the very provider that they link to and I still can't get in. I have an OpenID success rate of 0%. Why would I want to keep using it?
Which translates into "why the fuck should I trust OpenID to authenticate my users"? How can I, a website using OpenID, be sure that the OpenID provider hasn't been compromised?
If somebody is using OpenID and their OpenID account is comprimised, what is my legal liablity if the attacker "logs into" my website and fucks around with the user.
And by the way, what is the proper term for "user" in OpenID parlance? They really aren't "your" users, are they? Their account isn't with you anymore. It is with the OpenID provider. So what do you call somebody who logs into your website using OpenID? A visitor? A member?
what would be far more useful is an easy way to do single sign on between applications for a single website. I know LDAP exists, but it seems pretty complicated, or you can use half broken bridges, but somethign really simple would be incredibly useful. Or is there something I missed.
The nice thing about OpenID is he wouldn't have a banking login. You could just use his OpenID account and create one for him. Once you have his OpenID account compromised, you dont have to worry if he has an account anywhere. YOu can just copy & paste the OpenID into the website, use his OpenID login/password, and create a new one for him.
I think you just helped prove his point by misinterpreting "union" as modifying "set". See http://en.wikipedia.org/wiki/Rugby_union for a hint. :)
Are you talking gmail, or a corporate email account? If you have an email provider you can pick up a phone and call, these kinds of attacks don't exist. Sure they compromise your account, but you just call IT and have them un-compromise it.
Which actually says to me only a fool would register his OpenID account under a email account where you *can't* call the provider. If you bind your "mega-important OpenID account" to bob@gmail.com, you are gonna get screwed if the email account is compromised.
OpenID is tied to the Distributed Social Network project, which is as far as I can tell is trying to create some sort of platform (in the "cloud" sense) agnostic social network. Or to think of it another way, to make all the social sites play together nice.
Admirable goal. I'd like something like that, but let's be honest. It's doomed to failure because no one wants to play nice. Why? The entire valuation of the social sites is in their user base. They want people to come to them, and stay. There's no interest in making it easy for people to take data hosted on one site and displayed on a competitors.
While I like the idea of not being tired to some other group holding all my data, but still being able to share it, I just don't see other people playing along. Also, the only way you can share something, without relinquishing control of it is to set up your own severs, but very few wants to do that. (While I am perfectly capable of doing that, I choose not to, since life is much more interesting than patching servers and what not.) This means that you have to have someone host your data for you, and then you're back to where you started with someone else controlling your data.
but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ...
If it's a chicken-and-egg problem, wouldn't it be better to build a chicken trap, with egg catcher?
Actually, regarding this problem, If we can hit it bull's-eye, the rest of the dominoes will fall like a house of cards. Checkmate!
I love Wetpaint
It is lesser-known that the OpenID 2 specification includes support for i-names that are a form of the OASIS-standard XRI. An example of an i-name is "=chris.hills". The advantage over OpenID is that whilst the name is re-usable, the number associated with the name is not. If I decide that I no longer want my i-name and somebody else registers it, they will not be able to log into my accounts (assuming i didn't bother un-associating it).
I just signed up for this about a month ago. I should have known that would bring it to an end~
Why should I trust that somebody who wishes to use my website and uses OpenID to authenticate themselves?
If I'm a bank, is OpenID right for me?
What if I'm a web-based email provider?
What if I'm a site like youtube?
What about MySpace?
What about a health care company?
What about accounts on Newegg or Amazon?
What about bobs wordpress blog?
What about Slashdot?
At what "level of worthlessness" does a website need to have before OpenID is an ideal way to authenitcate their users? I'd say a bank would be stupid to use OpenID since you cannot trust random OpenID providers. But everything else is a gray area with no real guidance. When are you deemed "too important for OpenID authentication"? Who is the judge?
And respectfully, "OpenID isn't authenticating, their providers are" is a cop-out play on semantics. As a website requiring user authentication, I'm trusting OpenID the protocol to authenticate my users. The fact that the authentication is a bunch of other random untrustable websites is secondary.
http://shibboleth.internet2.edu/
So how about switching to to The Liberty Alliance (http://www.projectliberty.org) ? It seems like a serious alternative to Microsoft's Passport, and seems to have enough support in the industry to become a serious competitor to OpenID and MS-Passport.
I keep all my logins in one place: my head. For most places like slashdot I just use the same pair (I've never changed my original /. passwd.) Anyone that has known me for sometime knows this pair (hint, the username is either nethead, joe or w7com) I have a few more secure pairs that I use for my bank and domain register are a bit more secure. For routers and servers at work I just learn them, and mostly it's my fingers that learn them to the point that if I have to share it I would have to type it on a keyboard to be sure.
-- I have a private email server in my basement.
The answer to "which came first, the chicken or the egg" is very simple : the egg. If you accept evolution, then the first chicken hatched from an egg, that egg having been laid by a mutant proto-chicken.
My next sig will be ready soon, but subscribers can beat the rush
sorry for the grammer and spelling errors. Chrome has a shitty spell checker and I'm tired from a long day of work.
and how far our security in accessing remote system actually is *today*, i become pessimistic about software development.
Many people use a public OpenID provider. If you do, have you thought about it? You are granting an instance you barely know access to all your useraccounts on other websites. The convenient thing for the OpenID provider is, that he does not even need to guess which sites your ID might work with, but knows them through the authorization requests anyway. You have no way to prevent your OpenID provider to pose as you. You must be crazy to use a public OpenID provider!
Big players like Google aren't supporting the OpenID spec as it stands today.
Today you can't get true OpenID with any of Googles products, yet Gmail/Google Apps would make a perfect OpenID provider.
Area51 - We are watching...
What's all this crap about storing passwords on USB keychains and TryeCrype volumes and whatever else you kids are using these days? I store my passwords in my BRAIN, right next to the phone numbers and addresses. Its unhackable and the blood-brain barrier is very virus-resistant.
OpenID is a great system, and it's hardly dying. It's just changing.
The traditional (and right now, standard) view of OpenID is that you use a URL (or an i-name, which are all but useless because, hey, there's a lot of people qualified for =john.doe - and they are not free. How many people do you know with a .name URL?) to sign in to a website. This is pointless, because nobody wants to be identified by their blog when they log into facebook, or by their myspace account when they comment on blogger.
The way it's increasingly being used now is as a federated authentication mechanism, kind of like Windows Live Passport, except an open protocol. It's more or less completely transparent to the end user - I go to Zoho Office and click the button to log in with either Google or Yahoo, and it bounces me to the selected provider's OpenID page without forcing me to remember something like https://www.google.com/accounts/o8/id. That kind of system - transparent federated authentication - is much more likely to catch on with your average end-user.
There's an old saying that says pretty much whatever you want it to.
What the fuck is the "Read the rest of this comment..." link for if Slashdot already displays the whole goddamn 65 KB troll? That's 435 lines at 150 characters each.
Yes, but the difference is that Passport has worked reliably for years and years now... 10 years, if I'm remembering correctly... and I've yet to flawlessly log in to anything using OpenID even once.
Who the fuck uses Passport except other MS sites? I honestly thought that they killed it off years ago until you brought it up now.
Curious sig
--
.
"I've actually been quite happy with OpenID, since I have spawned far too many username/password pairs over the last 20-plus years, but it's a major chicken-and-egg problem. Hopefully someone out there will build a better mousetrap ..."
Is it just me or is old timmy starting to sound like the boss from dilbert?
A site I have never heard of stopped used openid, meanwhile the sites that I knew used openid and I have been used have not. This means openid is dying!
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
It's still goofy. Why the "="? OpenID is still silly relative to a proper login credential management system that could be implemented in browsers, using an encrypted credentials file that could be accessed from a file or a URL, and utilizing a standards based (once standards are made for this) protocol for logging in (HTTPS based).
now we need to go OSS in diesel cars
Especially since if it were true, sig-less posters would have penises of infinite size...
Yeah, and how is he supposed to decrypt it, in his head? I'm assuming of course, that he's not Bruce Schneier.
I don't even trust the Windows boxes in my own house.
I have two solutions:
So if you know ahead of time that you will be going to that friend's house, you can just change your password to a temporary one before leaving your house.
Forgot the third possibility --- boot into Linux from USB or mini-CDROM. I leave CDROMs of live Linux distros at friends houses just for this purpose!
I'm surprised that /. geeks actually use specific tools to manage their passwords, when it's so much simpler and quicker with a couple of shell micro-scripts.
Shell scripts are harder to use if you have to cut-and-paste between them and the browser.
You provided a windows batch file as an example... on that terminal, you have to open the console menu and first select mark, then draw a block around the text, and copy the text to the clipboard.
The browser's built-in manager is very easy to use, and as such, is used the most frequently. If that starts to fail or strain, you then switch to the other tools, such as keeping a plaintext file or building a greasemonkey script.
The main problem here is that OpenID was never a first-class citizen. If I go to a site that does support OpenID for login, which is a rarity, they only give the most basic of abilities to me. Whereas if I create a username in their system, suddenly I can create a profile for myself, set some preferences, etc. (Livejournal and Blogger being two notable ones.)
I really like OpenID, but my feeling is that companies never really wanted it in the first place. Sure the person running the site probably thought it was a great idea, but I'm sure the suits looked at it and thought "gee, I'm not going to be able to force my users to give me their full address and credit card before letting them do anything on my site, if they're logged in with this openid thing.." So instead, they use it as a teaser, and up-sell you on a real login. Of course, users aren't stupid, and if you're going to write comments on a blog and you think there's a hope in hell that you'll ever want to use the 'full' features of the site, you'll create a login instead.
What could save companies from this problem would be if they'd allow you to tie an OpenID to your login, and use that to login instead. (See stackoverflow.) But instead, a lot of sites prefer to use it as a way to avoid requiring a captcha for "anonymous" comments.
Also, it'd help if some of the big players weren't such dicks, and allowed you to login with an external OpenID rather than only exporting an OpenID.. It has to be a two-way street.
... is to free developers and service providers from significant account management burdens, and consumers from their own account management burdens, as well as the privacy and lock-in worries of some earlier attempts at federated identity. And all this while not burdening any of the participants with interoperability agreements or policy docs or contracts.
All of the above sounds good to me, but it may be that it is such a complicated message that it is hard to understand, or recognize its value.
It is clear OpenID has some usability issues and it is disturbing to hear that libraries for OpenID consumers aren't all equally functional. This wasn't our experience but we found what we needed fairly quickly and stopped looking.
Your comments surprise me a bit. For a tech-savvy crowd, I would have expected less nagging about a bit difficult implementation.
I've been using myopenid for quite some time and have no problems whatsoever.
It even lets you configure SSL certificates to authenticate yourself with, which is convenient and - until recently - pretty secure ;-)
The broken implementation of Yahoo et al. does not make OpenID broken by itself.
You provided a windows batch file as an example... on that terminal, you have to open the console menu and first select mark, then draw a block around the text, and copy the text to the clipboard.
People who actually use the Windows shell probably all have "QuickEdit Mode" enabled in the Command prompt window properties. Then you just select with the mouse and press Enter to copy, and right-click to paste.
I have this console-settings.reg file among my config files for new installs:
Windows Registry Editor Version 5.00
[HKEY_USERS\.DEFAULT\Console]
"QuickEdit"=dword:00000001
[HKEY_CURRENT_USER\Console]
"QuickEdit"=dword:00000001
Windows 7 has an option to link user accounts to an "online ID provider"; and when I asked what this meant, I was told it is OpenID. If so, could give OpenID a boost. More details here:
http://www.itwriting.com/blog/1134-openid-embedded-into-windows-7.html
Tim
As soon as I saw this article, I thought "How long before I see people completely misunderstand OpenID yet again".
You implemented it the only way it makes sense.
Yet you seem happy to trust Slashdot with your account details. Why is it some great breach of security if the same account details were used to, say, post to Slashdot, and comment on someone's blog?
Whereby securely means, no user information released.
The only user information you release is the same information you happily provide when you sign up for an account.
I take it you run your own email server, and Jabber server? Can't trust an external company knowing everyone you email, and everyone you chat to, right? Obviously it was much better when Yahoo users couldn't chat to MSN users, and it would be much more secure if you could only email someone if you also had an account at their ISP, right? Because using the same login details to be able to email all your contacts is such a security breach. These new-fangled things like Email and Jabber will never catch on!
Good, please let it die. OpenID is as if someone sat down and said to themselves "username/password is too damn quick and easy to use. lets replace authentication with a URL for a website no-one can remember (that still requires a username/password) and make it fragile and hard to implement! oh, and let's make it slow. sometimes. yeah, that's the ticket."
and then as a bonus, your password is in the clipboard for any application to read, intentionally or not. Good work.
-- 'The' Lord and Master Bitman On High, Master Of All
Has anyone ever tried to read or implement the OpenID spec? It's too complicated. The real problem with OpenID is that it's so complicated that it essentially requires a 3rd party library.
No, I will not work for your startup
Yet you seem happy to trust Slashdot with your account details.
I've had this account long before OpenID was even a whisper. And most places don't accept an OpenID unless it's through their service which leaves you in the same place.
What was your point?
Why is it some great breach of security
Reread what I said.
The only user information you release is the same information you happily provide when you sign up for an account.
Which is exactly the point.
What is your point? I fail to understand what your point is in the the first place?
Why? Because it does not solve the actual problem -- people having more account details to remember than they like while at the same time people want to keep some handles/passwords different.
Now, there is a very simple solution to this hassle. It is partly technical and partly a matter of shift in thinking. A website can have a traditional login system and still enable the user to have a single online identity (not necessarily a public one) over multiple sites.
The technical part is about *always* requiring an email as a login handle. To sign up, an average website asks at least for a screen name, password and an email, right? For every other purpose besides login, the website identifies the user by the screen name selected at signup. Think about it. Have you ever been infuriated because someone else has already claimed your usual screen name at a particular site? How about your email? Can anyone claim that without resorting to black hat, presuming that the website in question confirms the ownership of a particular email address?
The shift in thinking boils down to the understanding that the login handle can be different from the internal screen name. It should be. The user might want to be seen as "Jeff Cunningham" at photo.net but on piratebay.org he wants to be "jefferson". However, Jeff wants to login with jeffc@yahoo.com:V3ryG00d?P4ssw0rd at both sites. It doesn't matter if two sites have separate login systems. Everything is okay if the login handles are verified email addresses at both sites so the users themselves can decide which one they use.
My dear fellow slashdotters! All we must do is spread the messsage of Good Login Forms Use Email Adresses Instead Of Screen Names. Let the user decide which email/password combination to use.
i-names allows for a proper service resolution. One example of a service endpoint is an OpenID url.
I would have beat you if I could have remembered my login details...
OpenID and passwords have problems.
With OpenID, your provider could go down, or go out of business. Then you're locked out of all your sites. Screw that.
With passwords, every site has a different length, case, or punctuation requirement. You might use the same password for eBay and your bank (bad!). Your password app could break, corrupt your passwords, etc...
How about a solution where you control the one and only key?
GPGAuth
You verify the site either by a normal SSL cert--or by the fact that you've been there before and already have it's gpg key. Next it verifies you by the gpg key provided when you first signed up.
There's no place like