OpenID Foundation Embraced by Big Players

An anonymous reader writes "The OpenID Foundation has announced that Google, IBM, Microsoft, VeriSign and Yahoo! have all joined its board. It's exciting to see OpenID being embraced by such large players, but its also a concern that such big corporates are now directly influencing the fledgeling foundation. 'Today there are over a quarter of a billion OpenIDs and well over 10,000 websites to accept them. OpenID has grown to be implemented by major open source projects such as Drupal, cornerstone Web 2.0 services such as those by 37signals and Six Apart, as well as a mix of large companies including as Apple, Google, and Yahoo!. Today is about truly recognizing the accomplishments of the entire OpenID community which has certainly grown beyond the small grassroots community where it started in late 2005.'"

Re:Secure?

[esocid]

since authentication is handled by openid and not the scummy web server itself.

But what implications would it have for your account at any of those sites if your OpenID account is compromised or you password is cracked? I'm not too familiar with OpenID but it seems like an accident waiting to happen to me, but again I'm sure the security or protocol involved with all of this. I would rather have multiple accounts with different passwords, but I'm aware that some people use the same pass for all logins.

Re:A quarter _BILLION_?

[Tridus]

It is. Every account on Livejournal is also an OpenID account. It makes sense since the founder of LJ is also the founder of OpenID.

Re:A quarter _BILLION_?

[Bogtha]

Are you sure you don't have an OpenID? If you have a LiveJournal, you have an OpenID [livejournal.com]. If you have a Yahoo! account, you have an OpenID [yahoo.net]. If you have an AOL account, you have an OpenID [aol.com].

Re:A quarter _BILLION_?

[GuyWithLag]

Ah, it's not *one* ID everywhere. It's just one id for all low-impact sites (blog comments, simple sites that you need to register etc).

Re:A quarter _BILLION_?

[ceejayoz]

Yahoo! and AIM logins are OpenID logins, whether the users are aware of it or not.

The number is accurate. The assumptions you're making about the meaning of the number are not.

Re:Secure?

[Chyeld]

The way OpenID works (the "for dummies" version) is you go to a service which supports it and tell them "I'm Joe Joe from joejoe.com". The service then goes to joejoe.com and checks for the information there that would tell the service who to contact to verify you. It could be at joejoe.com itself, it could be openid.randomguy.com. It doesn't matter.

After the service knows who is allowed to verify that you are Joe Joe from joejoe.com, it asks them to do it. How they do it is entirely up to them. They could use a password/username. They could use a 32 point authenticaion scheme that at some point requires your mom to log in and ask you questions. It doesn't matter.

Once they've verifed you are Joe Joe, from joejoe.com, they tell the service that. Now, if the service considers itself 'high security' they can always do some extra checking before it logs you in fully (and some do). But if it's 'just Slashdot' then that's all that needs to happen.

So, someone hack your account with the group verifying you? Change authentication methods.

If you are implementing your side of OpenID correctly (and no it's not a given that you are) you have control over who verifys you as you and simply need to setup a different group to do the verification. YOU are in control of that. Unlike things like MS Passport, where you have to trust Microsoft not to foul up.

Of the single login setups I've seen OpenID is the best implementation I've run into. Yes, single sign on is inheritantly less secure than multiple sign ons, ASSUMING the authentication layer is equivalent across the board.

BUT, and this is the catch, YOU pick the level of authentication with OpenID. You get to decide how secure is secure, if you think it's ok to just go with a username/password. Then that's your choice and you can do that. But if you would prefer to go 'Fort Knox', it's entirely possible for you to do so, because you get to choose who does the authentication and therefore what authentication is being done.

Re:Well...

[Bogtha]

No, you are mixing up OpenID providers with OpenID relying parties. Yahoo and AOL are both OpenID providers, which means that if you have an account with them, then you have an OpenID. The sites you log into are OpenID relying parties, which means that if you have an OpenID you can log into them.

Yahoo and AOL don't have any services that are OpenID relying parties as far as I know (AOL say they are "actively working on it"). But you can use Yahoo and AOL OpenIDs to log into an OpenID relying party, for instance, if you have an AOL account, you can use your OpenID to log into LiveJournal, which is an OpenID relying party.

Re:Secure?

[dustman]

Also, there is one 'higher class' authentication layer implemented already, mentioned on episode 107 of security now podcast http://www.grc.com/securitynow.htm [grc.com] :

Verisign has an OpenID implementation, https://pip.verisignlabs.com/ [verisignlabs.com], with a plugin for firefox that makes it easy to manage signing into sites.

Verisign's implementation is already behind the paypal and ebay security fobs, and if you get a pip account, you can buy one and use it for secure authentication everywhere. They cost $30 from verisign, but only $5 from paypal: http://paypal.com/securitykey [paypal.com]

Re:Support on Slashdot?

[Bogtha]

I'm kinda worried that yahoo have - without my permission - put my username and password for them in the openid database.

There's no "OpenID database", it's decentralised. If you use your Yahoo OpenID on a website, that website sends you to Yahoo, where you are authenticated against the same Yahoo database that you've always had your account details in. When Yahoo decides you are who you say you are, they send you back to the original website. Your username and password haven't gone anywhere.

Re:Well...

[Jobe_br]

No, listen. You're wrong. This has nothing to do with sharing users, it has everything to do with YOU not having to create YET ANOTHER LOGIN. OpenID is about YOU not about the companies implementing it sharing users.

This isn't a trivial thing to understand and I encourage you to read up on OpenID.

Here's, in a nutshell, what it means. You have a Yahoo! or AOL account (so, you have a login & password, that you can remember). When you want to start using a product at 37signals, like basecamp or highrise, or whatever - you can CHOOSE to use your OpenID. You still have to sign up with 37signals, you still have to PAY 37signals, but you don't get another login & password.

When you provide your OpenID to 37signals, the APIs they use will ask your OpenID provider (e.g. Yahoo! or AOL) if you're authorized, your OpenID provider will ask YOU if you want to authorize 37signals, and you'll say YES.

That's it. Trust is setup, you've been in control the whole time, and now you can access your 37signals account without ever having created a new username & password.

It really, really is powerful. And it really, really is not trivial or necessarily easy to understand. But it works, and folks are getting on board with it.

Cheers,
[/rant]

Re:Support on Slashdot?

[hayesp25]

For a web site that is supposed to be geared towards technically capable people, there are some stupid, stupid posts here. There is no "openid database". Get a clue. Single-sign on is infinitely more secure than username / password splattered across the web. If your account gets compromised, you only have to lock down a single location. You can get a review of all authentication activity across all websites that you use. I don't understand how anyone can think this is not a good idea.

Re:Quite possibly

[benjymouse]

So, you want to see an actual example of a site with a seemingly perfectly valid SSL certificate but still sporting an exploit? Look no further than here: http://news.netcraft.com/archives/2008/01/08/italian_banks_xss_opportunity_seized_by_fraudsters.html [netcraft.com]. This is just a recent example.

This one example totally defeats all of your "security checks". And it is in the wild. You will of course claim that this particular attack was made possible by two factors: A XSS vuln at the banks website and users clicking on a link in an email sent to them. But the domain of that link was the banks domain. The XSS script was obfuscated. Once you arrived at the page everything seemed OK: There's a https:/// [https] at the front of the url, and the domain name is in fact the banks own domain name. Is the bank to blame? yes! Should anyone follow a link sent to them in an email? no! Did it succeed in having users giving up their details? you bet!

Incidently you don't "throw up a deceptive IFRAME". Iframes are embedded into the actual html. You can't tell it is there. Your address bar only tells you about the "parent" page. If the actual form lives inside an iframe - possibly generated by a XSS vulnerability like in this example, validating the URI means s***.

I really don't know which articles you've read on CardSpace. Do you only read the headlines and when CardSpace and Passport are mentioned together you assume that they are one and the same or that they are intrinsically linked?

Instead of FUDing (referring to "articles" without any concrete references) maybe you would like to point out what the problem with CardSpace is? I mean, apart from the fact that it originated from Microsoft which obviously is very disturbing to you.

Let me summarize CardSpace for you:

1. CardSpace is a de-centralized, open protocol based on XML. This is totally opposite Passport (although some Passport driven sites now allow you to use CardSpace as well).
2. CardSpace does not mandate any specific credential store. Not AD, not LDAP or anything. It is a procotol. If you have evidence to the contrary, please share it.
3. The client need not use AD or Windows or any other MS technology. IE on XP with .NET Framework 3.0 and on Vista already sports an AD free CardSpace card store.
4. The server/site (relying party) need not use AD or Windows or any other MS technology. There is even a proprosal for inclusion of CardSpace support into Zend Framework for PHP: http://framework.zend.com/wiki/display/ZFPROP/Zend_CardSpace [zend.com]. Google for more projects.
5. The (if one is used) issuing party need not use AD or Windows or any other MS technology.
6. Microsoft does not have a central authority. Microsoft is never in on the authentication (unless you authorize at a Microsoft site, of course).
7. I can make any number of "self-issued" cards, in which case there will be only two parties involved in the authentication; unlike OpenID id I may add.
8. Even if I use the same card against multiple sites, they don't get an identifier with which to compare my behavior across the sites. Unless of course my card includes something personally identifiable such as a unique email addy. But they don't need my email and I may question the site why the assert that claim.
9. CardSpace cards contain "claims", such as email adresses, names, etc. Some card you can issue yourself. But the relying party can demand that some cards are signed by a mutually trusted authority, like a bank or creditcard company. This could potentially spell the end (good thing) of handing out CC numbers on the 'net. The relying party can assert a (signed) claim that the bank accepts a withdrawal of a certain amount of $$ for a transaction. The shop never "sees" the CC#, merely a "signed"