Log in

Previous Entry | Next Entry

openID and DNS attacks

For some time I have been annoying people with my fixation on making certain both openID Providers and Relying parties take DNS seriously.

I point specifically to Sec 15.4 of the openID 2.0 spec.

Now most people don't read this far into the spec. Admittedly the spec authors also hedge on explaining the exact nature of the possible attack.

Today CERT has issued Vulnerability Note VU#800113, so now all the bad people now understand how to exploit potential DNS venerability's at openID Reliant parties, and how to use them to hijack openID accounts at those RPs.

I will point out that iNames are not effected by this if the RP is following the spec and using https or SAML resolution for XRI.

This relates to URL-based openID's such as http://ve7jtb.myopenid.com. If the openID provider is not using http redirects to send discovery to the https version of the url your account is vunerable to being hijacked at any openID relying party that is vulnerable to cache poisoning and other DNS attacks.

A simple way to test this is to type your openID directly into your browser bar http://ve7jtb.myopenid.com if you don't se yourself redirected to a https version of the URL, your OP is not doing all it should be to protect you.

You might say that when you enter openID that you enter something like ve7jtb.myopenid.com and expect that openID will automatically add the https:// for you. Well that would be an incorrect assumption. The openID 2.0 spec tells the RP to add http:// for backwards compatibility reasons, it is only if your OP redirects to the https version of your openID that https is used.

If you are only using your openID at sites for blog posts etc you may well not care.

One thing you can do is manually type https:// in front of your openID every time you log in.

The openID spec requires a RP to consider https://ve7jtb.myopenid.com a completely separate identifier from http://ve7jtb.myopenid.com.

If you have attached the http:// version to your account at a RP you would need to remove it or you will continue to be vulnerable.

On the Reliant Party (web site you are logging into) they MUST follow the spec and treat the two forms of the openID as two separate ID's and not automatically allow both to log in to the same account.

I am working on some feature tests for the upcoming OSIS I4 Interop

I will add that I have discussed this with openID providers who are not doing the https redirect over the past six months. Some have worrked to correct the problem others have not.

The results for library authors, openID providers, and openID Reliant parties who participate will all be publicly available. I like many of the authors of the openID libraries am doing this in my spare time, for the general good. So be patient as I get feature tests posted.

If people have suggestions for things that need testing please contact me and I will work with you to add them.

I am separately exploring using managed information cards for openID logins directly at Web Sites (RP), This will potentially be part of the Web services harmonization SIG at the Liberty Alliance.

My goal is to have a single login to a Web site that provides infocard, openID, and ID-WSF credentials. I think the potential simplification of the user experience could have significant benefits. However getting all three SSO camps together is not an overnight thing:)


Totally gratuitous view from my house today.



( 2 comments — Leave a comment )
Aug. 3rd, 2008 08:53 pm (UTC)
I should say
It's amazing
Mar. 2nd, 2011 07:55 am (UTC)
А вы знаете, что все форсажи скачать можно на сайте filmfast5.ru.
( 2 comments — Leave a comment )