Wednesday, February 21, 2007

OpenID and Unique IDs

George Fletcher, a really smart AOL guy, mentions in his latest entry:
One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.
I would agree that in the generic sense of an Identity Provider (IdP) that such an assertion holds. In some implementations, especially in OpenID's case, this obviously isn't true. This breaks when you depend on the user to serve a unique identifier directly to the verifying resource/service provider. Not to say that this couldn't be fixed in practice, mind you.

The discussion regarding reputation in his post is a valid one. I just happen to believe that it's more of a convenient "feature" that you can't turn off. There are a lot of situations where this is bad.

AOL's (Really)OpenID

Can someone please explain to me how this is going to foil a spammer's script?














Perhaps I'm just confused. I realize that it's just supposed to be a beta implementation, but it's going to be hard to sell OpenID even as a blog-spam panacea with these kinds of problems.

Also, could we offer some OpenID-relevant security tips instead of the mind-numbing password length/composition suggestions? How about verifying the use of https, an aol.com address, appropriate use, etc. This issue may lead into discussions regarding the level of exposure that the user has to the OpenID experience. How aware should the user be of the underlying technology? Some have suggested that such exposure be minimized; I would suggest the contrary in this case.

Tuesday, February 20, 2007

Digg and OpenID

Well, I knew it would eventually happen- a popular OpenID Digg article. I was curious, however, the form it would take. And now that Digg has thrown its support behind the initiative, the Web 2.0 community has taken notice. Here's the article I found:

Here are 5 reasons why I think OpenID Rocks:

1) 1 ring to rule them all - why wouldn’t you want the ability to have 1 sign-in across all blogs?

2) Bye-bye comment spam.

3) Verify who is actually making comments. Many fake Matt Cutts’, Jason Calacanis’ make comments and require verifying IPs or other time-consuming checks when prolific people do comment.

4) MyOpenID’s (inaptly-named) affiliate system is a nice tool for developers and large site owners.

5) De-centralized authentication leaves no single player holding all the cards.

Here are 6 reasons why OpenID sucks

1) It is (as yet) too complicated for average website owner to implement.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Now, there's a variety of misconceptions as well as informed points in this piece, but it represents the common perception of OpenID by a relatively "enlightened" Digg user. Similarly, the Digg comments always make for great reading. Here, a response to the above:
I'm getting sick of this FUD over OpenID. It has THE SAME "TRUST" AS EMAIL BASED AUTHENTICATION. The only differences are:

1. You can change your provider at any time but keep your same openID (a plus)
2. They can't send you anything (another plus).

YOU manage your authentication. They don't need to send you password resets etc. They don't have an email address to sell to a thrid party, or to spam you with their product "newsletters". OpenID is BETTER than email based account management.

The only true con is that you REQUIRE a website (1 page) to use one.


1) It is (as yet) too complicated for average website owner to implement.

Uh.. you paste a line of html into your index page.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

It's as secure as email as a login mechanism. If your webserver is compromised you lose. If you email server is compromised you lose. How is this any different?

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

Yes there is. You don't link to the fake Mark Cuban's provider in your page. It's as simple as that. What's to stop someone from making a fake email address claiming to be you?

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

This is called RTFM. Put "openid" into any search engine and there's your answer. If someone knows enough about OpenID to want one, they will be able to find out how to get one.

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

This has nothing to do with OpenID as a standard. Just the quality of the particular plugin you're looking at.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Your "security" on financial sites is only as secure as the email address you associate with it. Your online banking security is only as secure as your email account.

Just as with email, you can be your own provider. There is no requirement to EVER trust a third party.

The ONLY WAY to compromise an OpenID account is to either compromise the webserver hosting the link to the provider, or to compromise the provider. If your email server gets compromised its the SAME RESULT.
While I'm not going to sit here and detail the problems with both posts, it does represent the understanding and perception problem that OpenID currently has. I believe it only goes to further my assertion that OpenID is still not ready for the limelight. Digg's adoption of the standard is certainly a boon for the OpenID community, but it may lead to a new group of users which is blindly passionate about technology they do not fully understand. (See above)

I'm not posting this to disparage the Digg nor the OpenID communities, but I do believe that the OpenID guys owe it to their prospective users to discuss the pros and cons of the technology. (Some of which I described in my last post)

Friday, February 16, 2007

AOL OpenIDiocy

While the subject is intentionally inflammatory, I am simply frustrated how AOL can push a specification into the limelight which makes security worse in its current form. Unfortunately, the hype and ballyhoo which has ushered in the coming of OpenID has largely excluded any intelligent discussion of the security implications outside of the email lists. Now, I'm happy to hear about the integration and use non-phishable technologies with OpenID (such as Firefox 3.0 & CardSpace), though AOL's decision to move ahead without addressing the array of concerns is rather careless. Even if AOL's intention for the service is as a proof-of-concept or a demonstration, it exposes very real credentials and resources.

To reiterate the security concerns, here's why I won't use an AOL OpenID:

1) It places too much power in the hands of a potentially dangerous website. Instead of sending me to openid.aol.com/sn, I get sent to a similar looking site. In AOL's case, this is painfully easy to pull off given the simplicity of their interface. After naively providing my credentials to the site, all of my attached resources that I consider valuable are compromised. It puts any OpenID protected resource, my AIM account/email (if I used it), and any other resource where I might reuse the same credentials at risk. Now, I don't reuse passwords between resources, but how many people do?


2) It creates OpenID's for people who don't understand OpenID. I can now create a website that offers a login page that says,

Don't have an OpenID? You do if you have an AIM account! Log in right here:


and continue with my phishing attack. Now such an attack could admittedly happen even outside of the OpenID context, but it immediately taints the (otherwise) good work that has been done in the community. Even with a non-phishing OpenID site, does the average user realize that they're revealing their screen name to the site? Not a pseudonym/unique ID, but the actual user's screen name.

3) AOL's OpenID login interface does not have human-in-the-loop verification. How many AIM accounts are used by spammers currently? How trivial is it now for that account to be "repurposed" into a blog spamming account for those sites which support OpenID? OpenID's best defense so far to such threats has been the high-cost, low-return of setting up a spammer-sponsored OpenID provider. AOL's easily automatable interface, complete with innumerable already established dubious accounts, are quite likely to overcome this problem for them and form a blog-spamming haven.

Also, consider that the OpenID mantra has been operation in full promiscuous mode. When blogs start getting spammed, are they going to block all of AOL? Individual users?

4) The concept of having a unique ID on the internet just doesn't suit me, especially when it's my AOL ID. Now, many will say that this is "tin-foil-hat land", though I think this is just as bad, if not worse than, the Intel serial number controversy. Is it really that much worse that you have people actively offering the ID to sites rather than hardware doing it for them? At least the processor offered an obscure ID number with it rather than my AOL screen name!

And, if you think for a second that the fact that you consent to the transaction is any consolation, please refer to point #2 above.

-

There are further questions about the accountability between providers and websites, the ability to preform MITM attacks, and other privacy concerns, but the 4 reasons above should be enough to invoke some critical thinking. Some of these issues are with OpenID, while others are related to AOL's implementation, though all are arguably frightening.

I am not an opponent of OpenID. After the phishing problem is handled, I think that it will be a highly useful tool for authentication to low-value resources (i.e. most of the sites on the internet), especially when you understand the risks and implications. But it's just not ready for the prime-time yet. But with AOL's decision and the hype from the Web 2.0 crowd, it's already on its way there.

I would encourage anyone considering using this technology (either as a client or a implementer), to seriously research the security implications. Even more importantly, AOL should actively offer disclaimers regarding these issues. They're too important to allow a user to fall prey to a nefarious website.

Sunday, February 11, 2007

Crazy?

The latest version of the InfoCard integration guide calls out a problem that I groaned about earlier:

IMPORTANT NOTE: Notice that the URI used as the value of the ValueType attribute on the wsse:KeyIdentifier element to indicate a SHA1 thumbprint based key identifier is a slightly outdated URI value. The new prescribed value as per the WS-Security v1.1 standard should be as follows:

http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbPrintSHA1

Support for this newer URI will be added in a future versions of the Information Card Profile.


So as much as I would like to think that someone out there actually listened to my complaints, I realized that this was probably documented before I said anything. Oh well.

Success!

Ah. Sweet success. Finally.

A InfoCard compliant STS which issues credentials from a LDAP backend based on X509 credentials. A pursuit which was wonderfully enlightening, painfully tedious, and maddening at times. Thanks to an idiotic obsession to complete this thing and some limited help received from a Java PingIdentity guy on the MSDN forums about proper certificate hashing (!), I've got a working proof of concept based on the work of the XMLDAP work.

As I close the compiler and take a few deep breaths (and back everything up to a DVD-R), I figured I'd have a quick reflection upon a few things I've learned.

1) Microsoft hasn't seemed to dedicate the necessary support to handle developers' questions. Perhaps it was just the time of the day/week/year that I asked, but getting the ear of anybody of consequence on the MSDN forums was not possible. Simple yes/no questions appear to languish unanswered for weeks and months. I won't rant about this subject again, but an identity metasystem built upon open standards but with a closed reference implementation and no support can be just as frustrating to develop for as an all-closed solution.

2) PingIdentity announcement of their intention open-source their InfoCard related code (RP and STS) is just lip-service. I defy them to prove me wrong. :)

3) The CardSpace client wants WS-Security headers, but it really doesn't care what's included.

4) The CardSpace client will fail with a critical fault if it cannot write to the logs. It's a bug that's been identified in the MSDN forums, but it's pretty damn frustrating when the CardSpace client fails, causing IE to fail, causing Explorer to fail, eventually requires Windows restart. (for approximately 20 iterations when I thought it was my STS cards causing the problem)

5) One's progress on a given task is directly proportional to the demand for one's presence elsewhere. It is, therefore, impossible to get anything done.

6) As I continue working with the technologies, the more my mind wonders regarding use cases and applicability.

More to come later, but a good high-level start.

Tuesday, February 6, 2007

CardSpace Apache Module

Ashish Jain announced the release of the Apache CardSpace Module today in his blog. I'm really happy to hear that. Together with the Firefox 3.0 adoption of the spec, there should be plenty of tools to start piecing together some really interesting solutions.

But where is the bigger fish (IMO), the open-source STS? There is apparently some interest judging from the comments on his blog, but emails requesting access have thus far been dismissed. Or maybe it's just my emails.

My IDP Quest...

I'm still having fun in my IDP quest. I've successfully navigated the X509V3Credential issue thanks to some help from the MSDN board and despite some apparently bad or outdated MS doco.

What does that mean? I'm accepting requested along with a client certificate (which I trust), which is then included into the card I issue. When the user selects the card, the CardSpace client will retrieve the certificate from the appropriate store and use it for authentication back to the IDP. The IDP will retrieve attributes based on the certificate subjectDN from an LDAP, and send them back to the user in a SAML assertion. And then it dies.

Why? I'm not including the right WS Security headers in the response, if the CardSpace logging is to be believed. Which ones do I need to include? Got me. I don't know if it's a requirement set by the CardSpace client or by WS-Trust (which I'm admittedly not terribly knowledgeable about), but I'm working on it now. I'm going to review the spec to hopefully find some insight on the problem.

Saturday, February 3, 2007

Ditto...

As a frequent listener of STODID, I have to say that I'm in complete agreement with Paul. Not that I'm not interested in OpenID, but let's diversify a bit...

I'm glad Aldo is listening, however. Maybe some specific discussions about these technologies in the enterprise realm (and no, not just OpenID).

:)

(Not) Working with InfoCard

So I've got a working STS based on the work provided by the XMLDAP code- great work by the way. Issuing card and pulling user info from an LDAP, I'm really happy about how things are coming together.

Now if I can just get X509 authentication working. I've hit a few issues along the way, but the cards are kinda working now- they're at least importing correctly. I'm issuing cards with X509Credential identified with a SHA-1 hash of the certificate I want to use, but the Windows CardSpace client goes brain-dead when trying to find the certificate I specified. I browsed the MSDN forums looking for a solution, and I'm hoping that someone can clear up why this is happening.

I'm a bit frustrated at the problems I've been hitting; not because I because I have any expectation of a seamless development/integration process, but because I don't have the ability to examine the CardSpace client. As the de facto reference implementation for identity selectors, not supporting it is simply not an option (my personal admiration for the XMLDAP selector aside). Perhaps I've just been spoiled by the ability to load open source products into a debugger and figure out why things are breaking, but I hate being hamstrung by an issue that I could likely figure out with a bit more visibility.

Please, Microsoft- provide more context and detail on the client logging. A namespace error leading to an entry of "Inner Exception: 'None' is an invalid XmlNodeType. Line 1, position 1." isn't terribly helpful. I realize that this is a V1 release, but this is painful. When attempting to use the corrected card using X509, the client dies with a dialog box stating "The certificate associated with this card could not be found" and not so much as an log entry for an undoubtedly loggable event.