JimmyRidge

openid

32 posts in this topic

here is some proof about openid that can be done with openid

  • Phishing Attacks - this is probably the biggest concern when dealing with OpenID. Users may be tricked into providing their credentials to 3rd-party websites.
  • Man-in-the-middle Attacks - the connection is negotiated over DH (Diffie-Hellman) which is subjected to interception attacks. Ensure that you are using HTTPS.
  • Replay Attacks - the URL from the relaying party can be sniffed, unless over HTTPS, and as such being replayed. This is not that critical since if the attacker can sniff the wire/less they can as easy wait for the authentication to complete and then steal the session identifier.
  • CSRF Attacks - once the user is logged in attackers might be able to execute a series of CSRF (Cross-site request forgery) attacks against the identity provider or other sites where the user is logged in. OpenID makes authentication easer so why don’t we login everywhere?
  • XSS Attacks - once the user is logged in attackers might be able to execute a series of XSS (Cross-site scripting) attacks against the identity provider, in which case they will be able to hijack the entire on-line use presence, or other sides, in which case the attacker will be able to gain access to the session. Again, OpenID makes authentication easer so why don’t we login everywhere?
  • Miscellaneous Attacks - all other types of Web Attacks are applicable to OpenID clients and servers. The only difference is that the result may turn to be quite devastating.

A lot of what openID has is open ot CSRF attacks right now

Edited by kitche
0

Share this post


Link to post
Share on other sites
If I'm reading you correctly, it sounds like you're not quite there. You're asking if a site that uses OpenID for authentication gets compromised, does that mean that any OpenIDs on that site have been compromised... am I correct?

What I'm asking is... If a site that uses OpenID for authentication gets compromised through a pharming attack for example, isn't it possible for the attacker to collect the credentials as users enter them into the site?

If so, now they can be used on other sites that use the same authentication provider, correct?

0

Share this post


Link to post
Share on other sites
What I'm asking is... If a site that uses OpenID for authentication gets compromised through a pharming attack for example, isn't it possible for the attacker to collect the credentials as users enter them into the site?

If so, now they can be used on other sites that use the same authentication provider, correct?

No, because the individual site does not have any access to the openid authentication process. It basically hands off the authentication to the openid provider specified for that particular id, who runs the authentication and then passes a result back to the original site. This would be an example, using BinRev and Verisign:

BinRev: User provides openid (http://user.foo.bar/) --> BinRev: Site references URL and receives provider (Verisign) --> BinRev: Site passes openid authentication request to Verisign --> Verisign: Site performs authentication --> Verisign: Site returns "yes" or "no" depending on whether user passed authentication --> BinRev: If "yes", processes user login as normal; if "no", returns an error message to the user

Wow, that kind of sucks in plain text.

Anyway, the originating site never sees any of the authentication process at all; it just looks up where to pass the request to, and waits for an approved/denied response. An approved response would cause the login to proceed as if the user had successfully logged in locally (i.e. without openid) with a username/password. Any login cookies or session information would only pertain to that site; they shouldn't have any openid information in them at all.

0

Share this post


Link to post
Share on other sites

But if BinRev was compromised the attacker could simply simulate the connection to VeriSign, no?

0

Share this post


Link to post
Share on other sites
But if BinRev was compromised the attacker could simply simulate the connection to VeriSign, no?

It doesn't matter... VeriSign still does the heavy lifting. The connection info to the provider is not secret information, it is just basically the username (in the form of a URL). Here's one that I set up: http://shades.pip.verisignlabs.com/ -- just knowing that won't get you very far. Verisign still does the authentication. Even digging a bit into the source of that page gets you this:

	<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />

... which still doesn't do you (as an attacker) any good, since it still points back to Verisign.

If Verisign's servers get compromised, or if I pick a silly password that makes the authentication easy to guess, *then* there's a problem.

0

Share this post


Link to post
Share on other sites
But if BinRev was compromised the attacker could simply simulate the connection to VeriSign, no?

It doesn't matter... VeriSign still does the heavy lifting. The connection info to the provider is not secret information, it is just basically the username (in the form of a URL). Here's one that I set up: http://shades.pip.verisignlabs.com/ -- just knowing that won't get you very far. Verisign still does the authentication. Even digging a bit into the source of that page gets you this:

	<link rel="openid.server" href="http://pip.verisignlabs.com/server" />
<link rel="openid2.provider" href="http://pip.verisignlabs.com/server" />

... which still doesn't do you (as an attacker) any good, since it still points back to Verisign.

If Verisign's servers get compromised, or if I pick a silly password that makes the authentication easy to guess, *then* there's a problem.

I think maybe whats being referenced as a concern is if I pwn binrev, change the authentication server 'verisign' to go to one of my homebrew servers that looks VERY much like the verisign one, allowing people to enter their username and password, and grabbing that information, hence 'jacking' the OpenID of that user.

Short and simple, yes... any site or technology CAN be vulnerable to this attack. In the end it still comes to the same thing we have been saying for years... which is practice good browsing habits. When you go to enter your OpenID information into said Verisign labs, make sure who you are talking to is the real deal. The only information that binrev originally got at all from this was the username, which is plain as day if your using it anywhere, much like a web address. Thats the end of the authentication process for binrev, the rest is up to verisign to prove who you are is real or not, then let binrev know to trust you. The more eventful use that OpenID posed in this process was user creation, which where Binrev did not ever have a user Zapperlink, however by entering my OpenID, authenticating and using the profile of my choice for binrev, it will reply back to binrev, generating that user instantly, based on a positive authentication. Where openID is headed right now especially with Verisign and RSA is the Two Factor method which allows hardware authentication to be added in on top of just entering in your username and password into the authentication server.

0

Share this post


Link to post
Share on other sites
I think maybe whats being referenced as a concern is if I pwn binrev, change the authentication server 'verisign' to go to one of my homebrew servers that looks VERY much like the verisign one, allowing people to enter their username and password, and grabbing that information, hence 'jacking' the OpenID of that user.

No, you've not quite got it. BinRev has nothing to do with the OpenID... it all comes from my OpenID URL (http://shades.pip.verisignlabs.com/). Even if you set up your own openid server, you can't change that *my* ID points to Verisign's servers for authentication. BinRev just reads whatever is in the above URL and uses that info for authentication. The URL that you give out as your OpenID contains the server info, so as long as that page is secure, nobody else can modify it.

Put another way... my Verisign-based openid is only good on Verisign's server. If I tried to use that ID on another openid-capable server, it wouldn't have any idea who I was. There isn't a single central repository of openids... it's not some big grand universal identifier. It's just a way of offloading authentication from individual websites (again, like RADIUS). BinRev would have the option to decide which openid providers to trust... so maybe Verisign openids would be okay, but openids validated against some random rinky-dink provider based in Lower Strombolia that nobody's ever heard of would be suspect. :)

You would have to root Verisign's PIP servers in order to change the info or become privy to someone's username/password. All BinRev does is send a request to pip.verisignlabs.com/server that says "Hey, user shades.pip.verisignlabs.com is trying to sign on. Please do the authentication and let me know if I should let him in or not."

As an added extra step, the Verisign site has it set so that you can whitelist sites... and any other sites won't even be allowed to make authentication requests. So if I allow BinRev to make authentication requests, they will proceed as normal. However, if haX0rsite.com tries to contact Verisign to authenticate me and I never added that site to my whitelist, it will just return a failure.

I think what some folks are missing is that the protocol designers have already gone through the whole process in much greater detail than we have... so they've already thought about the "what if someone sets up a fake server" or "what if I spoof someone's ID" questions and provided robust solutions in the protocol. Verisign, Microsoft, IBM, and several other big-name companies have signed on to the advisory board... which does give tacit approval to the way things are going. And no matter what you may think of those companies, they do have a good bit of technical know-how and have people who are trained to check for this kind of vulnerabilities.

I'm not saying it's perfect, and I'm not saying I'm an expert on it. But my initial reading of it gives me the impression that it could work pretty well according to the design they've set up.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now