×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenID Warns of Serious Remote Bug, Urges Upgrade

timothy posted more than 2 years ago | from the slew-of-myriads-of-plethoras dept.

Security 45

Trailrunner7 writes "The OpenID Foundation is warning users about a weakness in the software that could enable an attacker to change some of the data exchanged between parties that use OpenID. The group is telling sites that implement OpenID to update to a new version in order to fix the problem. The bug in OpenID lies in the system's Attribute Exchange, an extension that gives sites the ability to exchange identity information between endpoints. OpenID, an open source project that enables users to prove their identity to myriad sites without providing their passwords, is used by a slew of popular sites, including Google, Yahoo and Flickr."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

45 comments

OpenID is a pile of crap. (-1)

Anonymous Coward | more than 2 years ago | (#36055708)

No shit. Everyone who isn't a fool knows that OpenID is a stupid idea, with a stupid implementation, and isn't very usable.

It's damn near impossible to log in to some sites that only support OpenID. Stackoverflow is a good example. It takes more effort to log in there than it does to just solve whatever problem is happening on your own.

Re:OpenID is a pile of crap. (2)

growse (928427) | more than 2 years ago | (#36055790)

I've not had to log into a stackoverflow site since the first time I logged in, about 3 months ago.

I conclude "You're doing it wrong".

Re:OpenID is a pile of crap. (-1)

Anonymous Coward | more than 2 years ago | (#36055822)

Lol, you keep cookies between sessions. You're doing it wrong too.

OpenID also warns of CmdrTaco's micropeen (-1)

Anonymous Coward | more than 2 years ago | (#36055714)

OpenID also warns that CmdrTaco's penis is smaller than a Japanese toddler's penis.

Re:OpenID also warns of CmdrTaco's micropeen (0)

Anonymous Coward | more than 2 years ago | (#36055744)

HAHA YOU SAID PENIS

Re:OpenID also warns of CmdrTaco's micropeen (0)

dugjohnson (920519) | more than 2 years ago | (#36055756)

So are you arguing that OpenID is sending inaccurate information? What's your point?

Re:OpenID also warns of CmdrTaco's micropeen (0)

Anonymous Coward | more than 2 years ago | (#36055772)

that CmdrTaco is hung like a toddle.

Backdoor (0)

Anonymous Coward | more than 2 years ago | (#36055736)

Fancy leaving out the NSA backdoor codes first time around. I'll bet they're pissed ...

One more down (1)

M0j0_j0j0 (1250800) | more than 2 years ago | (#36055746)

So, now, everyone is having a security auditing , guess why? By own experience, i can say , security is actually something you do not want to expend money on, of course when the shit hits the fan , it gets a pretty decent budget , until them, you are just paranoid!

RTF linked post (4, Informative)

Anonymous Coward | more than 2 years ago | (#36055800)

http://www.pingidentity.com/blogs/pingtalk/index.cfm/2011/5/5/Researchers-find-OpenID-vulnerability-sites-patch-hole

This only affects sites that use OpenID's AttributeExchange. If you just use it for authentication (and use the relying party's claimed identifier as the protocol advises) you are not/never were vulnerable.

The concept of OpenID doesn't seem very secure (2)

Bloodwine77 (913355) | more than 2 years ago | (#36055848)

I can see using OpenID for throwaway accounts, but I would never use it for anything serious. I use different passwords for every site I visit, so if one site gets compromised then my other accounts are still safe. OpenID puts all the eggs in one basket, and that just doesn't sit well with me.

Re:The concept of OpenID doesn't seem very secure (2, Informative)

Anonymous Coward | more than 2 years ago | (#36055876)

Given the average software developer's attention to security and the average company's attitude towards security, would you rather:

-Deal with the hassle of creating a new password for each site (possibly with some per-site algorithm, that with enough compromises, could be deduced), and the associated inconvenience of remembering them all

or:

-Put all your eggs in one basket with an OpenID provider that *does* take security seriously (Google, Yahoo, etc. can function as OpenID relying parties - and you can also use two factor authentication with Google now), so that basket is extremely well protected, and dodge the issue of giving random sites on the internet a password entirely?

Re:The concept of OpenID doesn't seem very secure (2)

abulafia (7826) | more than 2 years ago | (#36055944)

Put all your eggs in one basket with an OpenID provider that *does* take security seriously (Google, Yahoo, etc. can function as OpenID relying parties - and you can also use two factor authentication with Google now), so that basket is extremely well protected, and dodge the issue of giving random sites on the internet a password entirely?

That's easy. I would rather use per-site passwords.

Even if you trust Google's security without qualification, which you shouldn't, as they've been compromised before both internally and externally, there is the problem of interest alignment. Your interests are not the same as Google's.

As for deducing per-site passwords, well, if you can, then I'm doing it wrong, or you have either my master key or broken SHA2. And I don't remember any of them That is what password managers are for.

Final thought- if you've convinced yourself of the wisdom depending on the almighty Google (or Yahoo, or whoever), you might want to watch and see if they happen to upgrade their OpenID system in the next little bit. Just a thought.

Re:The concept of OpenID doesn't seem very secure (1)

tepples (727027) | more than 2 years ago | (#36056640)

I would rather use per-site passwords. [...] That is what password managers are for.

Which shifts the point of failure to each end user's computer: the operating system and the software used to store and retrieve these per-site passwords.

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36057348)

If you are going to have a problem, it's better to have it distributed where it only affects a portion of your users, than at a centralized point where when broken, creates a problem for everyone.

Sorry, I'm a firm believer in NOT using software to manage passwords. This is just a stupid notion to me.

There are so few sites that a compromised password will really hurt you. (Not to mention the tremendous number of sites where a login / password is completely unnecessary for normal use, yet insisted upon anyway.)

Use a throwaway login/password for the non-critical sites (and/or a password manager for those, if you want).

For those few sites where a compromised password would hurt you (financial, government, etc.), you would be foolish to trust a password manager, and not keep track of these yourself.

Re:The concept of OpenID doesn't seem very secure (1)

tepples (727027) | more than 2 years ago | (#36057496)

Any site that isn't exclusively ad-supported, such as any site that sells goods or services or takes donations, is "financial".

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36057648)

What about a site that isn't ad-supported, doesn't sell goods AND doesn't take donations?

Re:The concept of OpenID doesn't seem very secure (1)

abulafia (7826) | more than 2 years ago | (#36063900)

Of course it does. That's exactly where I want the risk for my passwords.

I'm not writing this from the perspective of an enterprise architect or a protocol designer, I'm talking about risk and incentives wearing the hat of an individual user.

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36056664)

Better yet, take your security into your own hands and become your own OpenID provider.

Re:The concept of OpenID doesn't seem very secure (2)

Dunbal (464142) | more than 2 years ago | (#36055890)

OpenID puts all the eggs in one basket.

Apparently it's more like a sieve than a basket. A sieve with very big holes where the eggs can fall out if you shake it enough.

Re:The concept of OpenID doesn't seem very secure (4, Funny)

brusk (135896) | more than 2 years ago | (#36055988)

If you're shaking a sieveful of eggs, the size of the holes isn't your biggest problem.

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36056058)

That's not all that he shakes, nor does he only shake his things in private. Yes, he does have problems, but what can you do besides institutionalize him?

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36055938)

I'd consider it a bit more useful if they sold a token (like the RSA SecurID or Blizzard Authenticator) that could be used to add heightened level of security. Otherwise it's just easier to manage separate accounts and keep the credentials in my keychain on my computer.

Re:The concept of OpenID doesn't seem very secure (4, Informative)

meba (2025382) | more than 2 years ago | (#36055950)

There are ways... You can for example get a Yubi Key: http://www.yubico.com/yubikey [yubico.com] , then get your own Drupal based OpenID provider: http://drupal.org/project/openid_provider [drupal.org] and use http://drupal.org/project/yubikey [drupal.org] module. Result? You host your own OpenID provider and everytime you want to use it, you need to have the Yubi Key - no one can steal your identity unless he steals your USB Key and your OTP

Re:The concept of OpenID doesn't seem very secure (4, Informative)

SuperQ (431) | more than 2 years ago | (#36056148)

Then you don't understand the concept.

OpenID allows you to keep your password AWAY from various sites. For example if I wanted to login to slashdot I can use any OpenID provider I want. This means that slashdot never gets my password. Slashdot gets a just-for-it token that my OpenID provider gives. If slashdot gets broken, no big deal that token can't be used for anything else, and my password is never released.

Guess what, I run my own OpenID provider so the only one to blame for loss of my authentication is myself. My own server is the only thing that gets the password and that exchange is done entirely over SSL.

Re:The concept of OpenID doesn't seem very secure (2)

dstar (34869) | more than 2 years ago | (#36056242)

OpenID allows you to keep your password AWAY from various sites.

I think you mean 'OpenID allows you to train users to be vulnerable to phishing attacks'. 'Never type your password into a page unless you went directly to the site' is good advice; 'Never type your password into a page unless you went directly to the site or the site that sent you there claims to be using OpenID' is not.

Re:The concept of OpenID doesn't seem very secure (1)

cduffy (652) | more than 2 years ago | (#36056934)

...which is why OpenID providers who take security seriously (such as Verisign) refuse to display password entry in any request with a Referrer field.

Re:The concept of OpenID doesn't seem very secure (1)

EMN13 (11493) | more than 2 years ago | (#36061256)

Not quite; it trains your users to only ever enter their password into precisely one site. In addition to which, under common usage you'll already be signed in and will rarely need to enter a password in the first place.

Also, your openid provider is free to use a less risky authentication method. E.g. if you use google's you might use two-factor authentication; a process that would be far too complex and annoying if it needed setting up for every site, but hardly problematic if used for just one or two.

Re:The concept of OpenID doesn't seem very secure (1)

Akzo (1079039) | more than 2 years ago | (#36060904)

How do you know that the page hasn't been hijacked and is sending your password and other credentials to a third party? Once they get your OpenID they get access to everything.

Re:The concept of OpenID doesn't seem very secure (0)

Anonymous Coward | more than 2 years ago | (#36066100)

You log into the OpenID provider directly, not via a cross-domain post hosted on the site you log into.

Avoiding OpenID due to myOpenID fiasco (1)

Anonymous Coward | more than 2 years ago | (#36056678)

Some time ago myOpenID.com lost all (or some portion) of their registered accounts (afaik this was due to Amazon's cloud trouble). Which was annoying because I used it for my stackexchange login. As it turns out, I could just recreate my login with the same name and voila I could use it to access my stackexchange account. That means if someone had created an account with my name before I did they'd have full access to my SE account.

I never realised how potentially broken things could get with OpenID and I'm being a bit weary about ever using OpenID again, even though I suppose I should've been more careful about what OpenID provider I picked.

Re:Avoiding OpenID due to myOpenID fiasco (1)

pslam (97660) | more than 2 years ago | (#36057216)

Some time ago myOpenID.com lost all (or some portion) of their registered accounts (afaik this was due to Amazon's cloud trouble). Which was annoying because I used it for my stackexchange login. As it turns out, I could just recreate my login with the same name and voila I could use it to access my stackexchange account. That means if someone had created an account with my name before I did they'd have full access to my SE account.

These are problems with myOpenID not OpenID. You're mixing protocol and provider.

I never realised how potentially broken things could get with OpenID and I'm being a bit weary about ever using OpenID again, even though I suppose I should've been more careful about what OpenID provider I picked.

You even say it yourself: you should've been more careful picking an OpenID provider. In any case, what did you lose? Nothing. What could you potentially have lost? A login on StackExchange. Many people would love to only have that problem.

Re:Avoiding OpenID due to myOpenID fiasco (0)

Anonymous Coward | more than 2 years ago | (#36057396)

I'm aware that OpenID != OpenID providers. But how can I tell how trustworthy OpenID providers are? I could have potentially have lost a lot more if I the myOpenID problem appeared later, I had only recently started using it and hadn't associated it with much yet. Actually, it's not just about LOSING my account, what you seem to have missed in my post is that after the provider's failure, *anyone* could gain access to everything I used my myOpenID credentials for, just by creating an account in my name.

So yeah, OpenID is only as good as its providers, and it's been demonstrated to me that they can be pretty damn insecure, ergo, I'm avoiding using OpenID for now. Using it for everything makes the OpenID provider I picked a single point of failure. I hate having to use seperate accounts for everything but at least when something bad happens, it doesn't usually affect anything else.

Re:Avoiding OpenID due to myOpenID fiasco (1)

pslam (97660) | more than 2 years ago | (#36057544)

So yeah, OpenID is only as good as its providers, and it's been demonstrated to me that they can be pretty damn insecure, ergo, I'm avoiding using OpenID for now. Using it for everything makes the OpenID provider I picked a single point of failure. I hate having to use seperate accounts for everything but at least when something bad happens, it doesn't usually affect anything else.

I just think this is like stopping driving just because one manufacturer made an unsafe car. You may be prematurely missing out - and making other people miss out - on what's potentially a good solution to password proliferation.

This is a complete over-reaction. (0)

Anonymous Coward | more than 2 years ago | (#36056978)

From someone who has done multiple OpenID RP and OP implementations, I'd say that they've completely over-reacted. First off, they are sounding alarm bells over Attribute Exchange, which isn't part of the core specification and by doing so are further tarnishing the brand of OpenID. There's no risk to the actual authentication portion of OpenID, which now causual observers will continue to thump their chests on how insecured the protocol is. Secondarily, _anyone_ who has ever read the AX specification knows that it says nothing about signatures in the security sections. It's designed for user-asserted data. If you intend to use it for something else (such as exchanging data verified by an identity assurance process on the OP), generally you would need to have made some out-of-band contract with your OP to ensure they were performing the assurance and signing the information.

How this should have been handled: the Attribute Exchange specification should have been bumped a major version with the new wording to indicate signature requirements on the part of the OP and RP. By declaring this "a bug" they are forcing a non-passive change on potentially thousands of RPs who are consuming AX from OPs and will break as they upgrade to 0.9.6 of OpenID4Java library. If they had simply bumped versions and implemented v2 in the library, then RPs who needed to require signatures could simply request v2 from the provider.

The point here is that the specification clearly doesn't require OPs to sign this extension, as it was intended as exchange of non-authoritative data. I think there may be a greater problem here that too many people were presuming that the data is somehow authoritative without doing any thinking for themselves. Nothing was stopping RPs and OPs from colluding to sign the extension under the current model (granted, the 0.9.5 version of OpenID4Java did not make this an easy task when I wrote an OP implementation that performed AX signing.)

The actual "weakness" (2)

Plombo (1914028) | more than 2 years ago | (#36057044)

The summary is very misleading. From TFA:

A group of security researchers identified a flaw in how some OpenID relying parties implement Attribute Exchange (AX). See below for information on the suggested fix. The researchers determined that some sites were not confirming that the information passed through AX was signed. That allows an attacker to modify the information. If the site is only using AX to receive low-security information like a users self-asserted gender, then this will probably not be a problem. However if it is being used to receive information that it only trusts the identity provider to assert, then it creates the potential for an attack.

There are no AX attributes that all providers are required to support, nor are there any (as far as I know) available from enough providers to "trust the identity provider" for. Even the basic ones like name and email address can't be relied upon.

Before you log in to a site using OpenID, if you have a decent provider (Google and Launchpad both do this; I don't know about others), it will tell you exactly what information the relying site is asking for, and what it's going to send to the relying party. I have yet to see a relying site that uses AX for anything other than my email address and sometimes my name. And once you register on a site using OpenID, the site will ask you for that information anyway using the AX attributes as default form values if they are available, since AX can't be relied on to provide the information. This "weakness" in OpenID only exists for relying sites that use AX for "information that it only trusts the identity provider to assert", which only exist in theory. Calling this a "serious remote bug" is a joke.

And most importantly, the summary doesn't make clear that even on the theoretical sites where this is an actual problem, your login and valuable personal information cannot be compromised by this vulnerability, because AX is not used for any of that. That is what a "serious remote bug" in OpenID would be.

Misleading article & summary (1)

ArwynH (883499) | more than 2 years ago | (#36057046)

I just RTFA and it is just as confusing as the summary. I wish blog authors would at least try and understand the subject before writing about it.. OpenID is a specification. As far as I can tell the specification is safe, so implementations that follow the specification correctly are safe. However it seems that there are a few implementations that skip an important part of the process, namely input verification. Basically saying OpenID is broken because of this is like saying SQL is broken because some sites are vulnerable to SQL injection attacks.

Re:Misleading article & summary (1)

EMN13 (11493) | more than 2 years ago | (#36061282)

It's more akin to saying that SQL is broken because some versions of PHP allow SQL injection. The bug was in two common library implementations and can be fixed merely by updating the library... I also love how the article sensationalizes the issue and calls this a "serious" vulnerability... how exactly is this vulnerability going to be exploited in a "serious" fashion? That sure doesn't sound easy to do for most openid uses...

Slashdot OpenID (1)

theCoder (23772) | more than 2 years ago | (#36059442)

Somewhat OT, but what happened to the ability to log into /. with my open ID? My account still has the OpenID associated with it, but the login area for /. doesn't seem to let me use an open ID anymore. Or is there a lesser known login area that lets one use open ID?

An explanation of the issue. (0)

Anonymous Coward | more than 2 years ago | (#36063204)

To be clear. The vulnerability is not about passwords, or really anything at the identity provider.

The openID attribute exchange extension allows attributes like name and email to be sent along with the authentication.

Those attributes being self asserted are not required to be signed to prevent tampering.

The logic being that if you can put anything into those fields at your identity provider why would a user tamper with them on the wire to change them.

The AX extension allows for the signing of those elements.

The problem is that some RP were violating the spec and treating a unsigned email address from the OP as the users identifier and trowing away the rest of the authentication message.

The exploit required the RP to:
a) violate the openID spec
b) do it without without at-least checking that the email came from the OP rather than being self asserted by the user.

So in the end, the fix was asking those RP being affected to stop violating the openID spec.

The more interesting thing to explore is why they ever thought that this was a good idea.
Given that more than one RP was involved, there is a element of group behaviour causing people to make bad security choices.

John B.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...