Slashdot Mirror
AOL Now Supports OpenID
Nurgled writes "On Sunday John Panzer announced that AOL now has experimental OpenID server support. This means that every AOL user now has an OpenID identifier. OpenID is a decentralized cross-site authentication system which has been growing in popularity over the last few months. AOL is the first large provider to offer OpenID services, and though they do not currently accept logins to their services with OpenID identifiers from elsewhere, they are apparently working on it. The next big challenge for OpenID proponents is teaching AOL's userbase how to make use of this new technology."
I'll have a personal Identification PIN number please, what the hell is an OpenID identifier if not an OpenID ID?
People who don't want to manage 5000+ usernames.
So the idea is pretty cool... Now that you've got an OpenID, you could go ahead and use that login on whatever else supports OpenID. The problem lies with the fact that 50% of AOL's userbase doesn't even own a computer. According to some stats that AOL released some time ago...
The people who don't want to manage 5000+ usernames just use an universal password. Universal passwords are useful, if your friend just told you their password by mistake. Then you'd have acess to their entire life, g-mail and all.
Single sign-on across the internet is a bad idea. As more sites require it, people's web browsing habits will be tracked on an unprecedented scale. Seriously, what benefit does it provide? I certainly don't want to log onto my bank's website automatically. And in general, I don't want to reveal anything about my identity unless there is a very good reason to do so. The whole purpose of OpenID and similar technologies is to make it easier to track people. This is not the way I want the internet to develop.
It's a last ditch effort by AOL to stay relevant to the rest of the InterWebs.
Signature applied for, Patent Pending
Can't teach an (A)OLd dog new tricks.
Except for the sub 10% of AOL users who know what they are doing, most of them will be confused and confounded by just even the idea of OpenID, let alone how to use it.
Trust me, I worked with these people for almost 3 years. You know there's little hope when you tell them to unplug just the power to their DSL modem, and explaining which one the power cable is, but they unplug the phone line anyways.
AOL needs to go down, so their users can learn for themselves.
Has anyone got any precise insight on the difference between OpenPrivacy and OpenID goals? :)
One major problem I see with this sort of initiative is spoofing of your provider's sign-in page. Unlike spoofing in its current form, if someone was able to get the password for your OpenID provider, he'll have access to every single one of the accounts you've used that ID with. It's putting all your eggs in one basket -- with the way everything is currently handled, your sign-on information to an individual site may be compromised, but you won't lose everything else.
Is there a solution to this kind of problem, or is OpenID really only targeted to low-risk authentication; i.e., for forums and social networking sites?
No comment.
What was so broken that they needed to be unplugging the power to their DSL modem?
Nerd rage is the funniest rage.
OpenID is the phisher's dream. I honestly don't get what would motivate someone to implement this specification.
The fact that you cant even get a nick like DirtyTurtle278346812376 because it is already taken, why the hell would it be a good thing for something like OpenID to be poluted by AOLs obnoxious user list?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
OK, other than NOT being MS driven and a bit more open, where is OpenID conceptually different from Passport? I may have missed something here but it's again single sign on which concentrates your online identity into a single point of failure.
So, it's more modern and has a little shiny "Open" sticker on the side, but the challenges are identical IMHO.
Insert
FINALLY!! Now it'll be sooo easy to hack peoples important accounts. You make a spoof page for something really irrelevant that no one cares about, they sign in without thinking twice because its not a site they are bothered about at all and BAM I suddenly can use that info to Login to their bank account where they would normally triple check the website address and where the bank has put 3000 security features. I LOVE it!! Come on OpenID - I've been trying to figure out what I'd do to retire ;)
Wooosh!!
"Without deviation from the norm, 'progress' is not possible." - Frank Zappa
Who else woke up this morning to smell the fascism?
... the balance immediately tips over to the negative once infrastructure .. and then locked down and made mandatory.
While it sounds like a great idea in fact... it is not. On the pro
side people don't have to keep lists of their accounts and passwords
across many sites and sites have a standardized mechanism to rely on...
like OpenID is established
Think what it could be like when sites only accept OpenID authentication
coming from certain sources like the provider your IP is originating
from? Take it one step further, think what it would be like to authenticate
with your OpenID URL to get onto the internet itself?
The idea sucks and I didn't even get started on how it allows the operator
of an OpenID authentication service to track which sites you go to.
So? If someone tells you their openid (or you setup a spoof website to get it) then you have access to their entire life too, if this becomes popular. There is *no* difference.
The only 'universal' IDs that aren't open to such an attacks are things like biometrics and one time pads.
The story is even bigger than the summary makes it out to be. It's not just AOL users who have an OpenID -- anyone who uses AOL Instant Messenger is included, too, as is anyone who uses AOL's "Journals" blogging platform. Both these services are free, and AIM especially is used by a far wider and more technical group of users than the term "AOL users" would suggest. (You /.ers who use AIM via Gaim, for example? You've got OpenIDs now.)
Read my blog.
but you're that person's friend, so you wouldn't steal their identity...would you?
The next big challenge for OpenID proponents is teaching AOL's userbase how to make use of this new technology.
I think I see the flaw in your plan.
Technoli
Something tells me no matter how idiotic a bank is they would NEVER implement OpenID as the sole login requirement for internet banking. You'd just be asking for it on an immense scale. I hope you weren't going for a funny modifier because this just came across as ignorant.
The joke is often repeated. But U.S. trademark law may help explain RAS syndrome. Trademarks are adjectives and should be used with a generic term, even if they contain an abbreviation of the generic term. Hence "TCBY yogurt" even though "TCBY" is "the country's best yogurt", "DC comics" even though "DC" was "detective comics", "SAT reasoning test" even though "SAT" was "scholastic aptitude test", and "SPAM luncheon meat" even though "SPAM" stood for "specially processed assorted meat" at one time. Writers pressured by trademark owners to include the generic terms in their copy tend to overextend the habit of abbreviation + generic even to cases where the abbreviation is not a trademark.
Another cause is to disambiguate homophonic or homographic acronyms. "Put your PIN in the computer" could be misheard as "put your pin (or pen) in the computer", which could damage the machine. "Put your PIN number in the computer" has one interpretation.
Isn't that the purpose of GATOR?
AOL did not develop the OpenID 1.x spec and they are not developing the OpenID 2.0 spec.
.NET that are under the LGPL. The Ruby library is under the Apache license. Many open source projects (Apache, MoinMoin, MediaWiki, Drupal, Plone, etc.) have implemented OpenID or are working on it.
OpenID was originally developed by Brad Fitzpatrick of LiveJournal, and now it is being developed with an open process, involving many open source hackers and tech companies. Anyone is free to implement the specs.
There are already OpenID libraries for Python, PHP, Perl and
Climate Progress - Hell and High Water
So this topic is currently being debated in my company. The question is when should one centralize or decentralize authentication/authorization? Seems to me that it depends on the system and what your trying to protect. At my company we currently have email systems, websites, computers, and other resources that all have separate authentication/authorization. The problem we are seeing is that maintenance of these systems has gotten out of hand, leading to users who have left the company still having access to some resources. Thus, decentralization has lead to security risks. This makes it hard to rotate passwords in a reasonable manor, also a security risk. Seems to me however, on the internet this may be a bad idea. If my yahoo email is compromised, I like the security of not having my bank account also compromised. The single point of failure is a major security risk. That being said I have worked on a few bank websites and have several examples where a users account was compromised, and we couldn't find any compromise of our system. After lengthy discussions, it turns out some other site the user was using was compromised, and the user just happened to be using the same login and password with us. You can scream education all you want, but only having to remember one password is what users really want to do. So I ask \., when do you centralize and when do you decentralize? There must be some set of rules here. Maybe decentralize when your protecting the system itself, but centralize when your protecting a single resource in a big system?
When are they going to reimplement AIM via Jabber, so that AIM users can easily talk to Google Talk users and everyone else?
That would leave only Yahoo and MSN...
But really, it seems obvious to me that they are not implementing OpenID because they like open standards. Otherwise, why aren't they actually using open standards elsewhere?
Don't thank God, thank a doctor!
Thank you for your knee jerk reaction but I was talking about what's
around the corner once schemes like OpenID are widely adopted.
Most talk about OpenID is on the big Internet but I thing it could be used within a big company's Intranet quite nicely. There are always diverse systems that require logins. LDAP is the current "solution" but its quite a pain.
This is the OpenID Administrator. We had a server crash and must rebuild our database. Please click on the link below and begin the process of verifying your OpenID information. Failure to do this will result in your OpenID account being disabled. This request is mandatory for you to comply.
We apologize for this inconvenience.
The race isn't always to the swift... but that's the way to bet!
Everybody else does and it is managed by the friendly revenue service for the benefit of all Americans. There is no need to invent a new set of numbers... ;)
Excuse me, but please get off my Pennisetum Clandestinum, eh!
All you have to do is pick a unique enough username that nobody else has come up with it yet. Just make it related to something you like and it's very simple. Take mine for example
electro: electronic music
soccer: sport
tux: mascot of Linux
I've never had a problem getting this username registered anywhere.
The same goes with your password. Just cook up a sufficently secure password that is at least 12 characters long and then use it everywhere. Since you're going to be typing it in a lot, make sure it's easy to type.
It seems OpenID prevents this problem. With OpenID the only thing you give to the websites you login to is your URL (such as https://aol.com/cooldude ). You can even give your URL to your enemies. You never give your OpenID password to any site except AOL, or if you run your own OpenID server, you never give your password to anyone at all. If I understand it right the whole encrypted procedure goes something like this:
You're trying to login to example.com
Example.com says: Who are you?
You say: I'm "https://aol.com/cooldude"
Example.com asks AOL: Is this guy really cooldude?
AOL sends a message to you asking: Example.com says you're trying to log on, is it really you?
You say to AOL: Yea it's me, here's my password to prove it.(AOL doesn't tell example.com your password. Also you save the hassle of entering your password for any site if you already logged in to AOL, like at the beginning of each day.)
AOL says to Example.com: Yes we verified it's cooldude.
Example.com says to you: Hi cooldude from aol.com, we've verified it's you again. Welcome.
Note that if you log into AOL at the beginning of the day, then for you this whole procedure boils down to you just entering your URL to login and then pressing a button from AOL to authorize the login.
Some advantages and disadvantages are:
You can use one username and password for every site and you only have to enter your password once a day.
If you used the same username and password at a lot of sites before, then with OpenID you don't have to worry about your password being compromised on one site by lax security or a crooked site owner(like a phisher) and then having your accounts compromised at all the other sites.
I'm not sure about the privacy issues. If your OpenID provider allows it(or if you set up your own server) you could set up an unlimited number of ID's (eg cooldude2, cooldude3, etc.) I don't see how you would be giving up any more privacy than any other system. And if your provider allows it you could save a lot of trouble and use the same password for all your IDs. Your OpenID provider could track which sites you log into, but you could just be your own provider or choose one you trust not to track you. Of course the sites you log into could require only certain OpenID providers like AOL, Microsoft, Verisign, etc. You might not be able to use your own server. Sites might only accept OpenIDs from providers that use strong identification, like Paypal's requirement that you control a checking account to be confirmed, because banks in the US are required by law to get ID before opening a checking account(says Paypal).
If sites only recognize OpenIDs from certain providers, at least the list of providers would likely be more inclusive than something like Microsoft Passport which has only one provider.
OpenID providers might differentiate themselves on their security. Verisign for example may try to claim that their OpenID service (if they had it) is secure enough to use for bank logins.
broadband modems sometimes crash when they are either defective or damaged by the user, power cycling them can help sometimes
Snowden and Manning are heroes.
This all seems well and good, but wouldn't it be trivial for someone to pull a DNS cache poisoning stunt and redirect openid.mydomain.com to their servers instead? From what I recall of SSL/TLS the thing that prevents this from happening is if one has a certificate and the client implementation actually bothers to check it ... but nobody has a certificate, they're expensive and a pain in the arse.
So, seriously, what stops this from being the most exploitable authentication system ever?
Dave
I write a blog now, you should be afraid.
...since the trust model is broken. Trust DNS? Not.
It's good for blog log-ins, but not for banking
BWilde
Actually, the problem is that the OpenID specification is very poorly written and is extremely complicated. It's as though a couple of kids wanted to put together an RFC but didn't really understand how to express a specification is a logical form. If you don't believe me, just take a look; you'll see what I mean just by glancing through it: http://openid.net/specs/openid-authentication-1_1. txt
Anyway, then, as kids are wont to do, they have followed it up with a series of new specifications, each one more complicated than the last. There are five specifications in draft form right now, each to cover some different aspect of what should be a fairly simple protocol. They reference and make use of HTTP, HTML, XHTML, XML, XRIs, XRDS, S/MIME, XSLT, and some other, similar ID specification called Yadis. Implementing all this thing requires gobs of software libraries (each with security holes and bugs) and expertise (and who has time to learn the latest X??? spec?). And we're supposed to believe that it's possible to do this securely? We can barely make secure web servers, much less SSI systems which require almost 100 pages of specifications, plus thousands of pages of supporting specifications!
What's sad is that the authors are not just a couple of kids that discovered XML and had a field day. The authors are associated with companies. The primary author works for VeriSign. Presumably, he should know better than to make such a jumbled mess.
But I think we all know what's really going on here. These idiots put together an incomprehensible specification. It is poorly defined, ambigious, and relies on lots of supporting technologies. It is impossible to implement securely, completely, and correctly. Security holes and interoperability issues will be the only real standard. And guess whose jobs are secure? Guess who gets lots of contracting jobs? Guess who is needed to write new specifications so that they can get it Right the next time?
It's too late to turn this one around. Hopefully OpenID will die a horrible death and we'll never hear of it again. But please, please, if anyone else reading this feels compelled to write a specification in the future, learn from OpenID's mistakes and keep it simple, stupid. Because OpenID is setting itself up for disaster.
If you have to login with protectnetwork.org because that's what your school uses for access to the online library services and such, you also have an OpenID because protectnetwork works with that.
I think all the independent "Identity Provider" services are going to end up being interoperable with each other, probably via all becoming part of OpenID. It's just too useful, for it not to happen.
One issue I see is users not realizing that it all becoming interoperable, and signing up for multiple identies by accident -- if a site doesn't have a "log in with protectnetwork.org" link very obvious, they will sign up for a new account.
"Of course, many here on Slashdot could probably set up their own OpenID server that has a unique identifier for each site, but how many do you think {are going to/are able to} do that -- especially among AOL users?"
And how many people could rip and encode a DVD before hackers made it easy?
Maybe we could distribute a mod for one of these for our AOL using friends.
Here are several reaons that I wouldn't implement OpenID
1. I'm relying on a third party to authorize a person. A potentially untrusted third party. Some sites have credibility already (livejournal.com, aol.com even if AOL does suck), but as I understand it, ANYONE can create an OpenID server.
So, what's to stop someone from creating one that authorizes any username/password given to it?
2. It really messes up my database normalization. Handling local users and remote users would take more database tables, with fairly uncontrolled inserts to the second table. With a local authentication method only, my foreign keys are all nice and neat.
3. It adds an additional (and unnecessary) network layer to my authentication system.
So, thanks, but I'll stick with local authentication, be it a database or LDAP system.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I'm certain OpenID would be more widely adopted, if actually setting it up weren't such a PITA. I've tried it twice, and at least for the PHP libraries, there are numerous inconsistencies, lack of documentation and version conflicts, that unless you're devoted to the idea, the approach of "heck, why not, it's nice to have" doesn't give you enough incentive to get it done. I've tried a third time just today, using the Wikimedia OpenID extension, and no luck. Segmentation fault, no docs explaining more than the bare essentials. It certainly looks a lot like the OpenID implementations are still in beta.
I like the idea, but as long as it's such a hassle to get it running, AOL and others who are either fans of OpenID or have the resources to simply tell a few coders to get it done and take a week if need be, that's where you'll find it and nowhere else.
Assorted stuff I do sometimes: Lemuria.org
I'm honestly flabbergasted someone on /. would ask this...
DSL and Cable modems have a tendency to lock up. May it be line noise, overheating due to bad placement, or the connection is up and down so fast it just locks up. Some of these devices have a reset button on them, or even a power button, and sometimes these work just fine, but most of the time you have to pull the power completely, standard time frame is 10 seconds, to reboot the modems.
When I worked on the support end for AOL, I was in a broadband que, and took calls from thee customers exclusively. We had 3 kinds, none of which was better than the other; Cable, DSL, and BYOB (Bring Your Own Broadband). DSL was the worst, not even because of the customer either; we were disallowed to contact the user's phone company to get thigns resolved. We had to place a ticket in with out higher up DSL team, and they'd do it. Added days to support issues.
I admire the dispersed nature of the whole idea, but I fail to see the point if a logon doesn't carry a degree of associated trust. If anything, it goes against any trust model as there are too many uncontrolled parties involved who may or may not have an interest in your browsing habits. It's a bit like a store card where you get some peanut reward for given the shop/chain the ability to analyse your shopping habits in minute detail.
So you've got nothing to hide? Fine, would you appreciate being followed by someone taking careful note of everything you buy? No? Well, the only difference is that the stalker is invisible.
No thanks.
Insert
Your'e creating a single attack vector for multiple sites - any site who uses the scheme will show up in a log as a site your ID/password gives access to, and a compromise of teh core service (or the section you use) will thus screw you for all those sites in one go. Not to mention the risk if someone comes up with an idea to intercept/divert the authentication traffic.
Maybe my standards are too high, but it doesn't feel like a very good idea to me other than for very low value sites (i.e. those with no money or reputational risks involved).
Insert
There is already a reasonable system to assure identity (reasonable totally trustworthy): the Web of Trust scheme from Thawte (the reason Mark Shuttleworth could collect airmiles in a more spectacular way :-). The WOT idea uses a points system and ID cross checks to give people certificates.
..
I should know because I was one of the people authenticated into the system by Mark, but I must log in and update my data
Insert
Boy, that sure does sound great. XRI promises global context symbols, peer-to-peer addressing, decentralization, delegation, federation, persistence, human-friendly formats, machine-friendly formats, lightweight resolution, trusted resolution, and transport independence! Amazing!
/, .), all with meaning (they "provide a simple, human-friendly way to indicate the global context of an i-name or i-number.") Hah!). HTTP requests and XML parsing to determine the real location of anything ("lightweight resolution"); this means at least 2 HTTP GET requests to resolve the location of a resource. Wow, persistence with numbers! Couldn't have done that with a simple UUID scheme! And what's with having a machine-friendly format and a human-friendly format? If every machine has to be able to parse them both, then why bother with the bloat?
Too bad it's all a bunch of complicated bullshit. We don't need it, and we don't want it. Want to know why? Seven different special symbols (@, +, =, !, $,
I fail to see how any of this will allow you to develop anything you've mentioned. If anything technological is holding us back from general programmatic contracts, it's not a resource identification scheme.
Luckily, this will never catch on. XRIs have no use cases. Why would I want xri://@example.org*blah=Bob/ when http://blah.example.org/Bob/ already works with my existing software without any problems? My only fear is that OpenID 2.0 will require that all software understand XRIs. So much for lightweight software.
...what OpenID is. What's an 'AOL'?
Have gnu, will travel.
I'm a fan of RESTful systems and, while I introduced the XRI folk to SAML, I've also been helping to show how all that SOAP bloat isn't necessary.
And I'm also not a big fan of global name spaces, which @, + and = are used for. They can be a useful shorthand, but =bob and http://xri.neustar.net/bob could be defined to mean the same thing - and there are proposals for this on the table.
The real win comes when you want to do things that just can't be done with URLs such as alternate resolution protocols (say, use Freenet-style DHTs instead of DNS), provide for symbolic links and back-references, and - most importantly - enable trusted, negotiated resolution and access to services according to source and destination without disclosing any unnecessary information about either party.
Yeah, it looks complicated, but http://example.com:8008?q=43&foo\0e=72 looks kinda foreboding too. But we're used to the "://" syntax and we have browsers that make it easier for us. Don't throw away the tech because you don't understand it - there's some very real benefits to XRI, and you can bet that if it catches on, the most useful applications will quickly be sheathed in Web 2.0 GUIs that hide the complexity as they realize the power.
Finally, one can always delegate XRI resolution to a proxy resolver, so apps that need to stay lightweight can remain so.
The antidote for misuse of freedom of speech is more freedom of speech.
-- Molly Ivins