OpenID Security Issues: Protocol and Browser

From IIW

Session Number – Space/Location Letter: Day 2 / Session 1 - B and Session 2 -B

Convener: Breno de Medeiros, Michael Hanson

Notes-taker(s): Michael Hanson

A. Tags for the session - technology discussed/ideas considered:

OpenID Security, Phishing, HTTP, Strict Transport Security, Content Security Policy


B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

OpenID Security:

Discussion is held on this list: http://lists.openid.net/mailman/listinfo/openid-security


Protocol Discussion:


Flow for authentication: Flow1.jpg

Flow for association:

Flow2.jpg Threats: Solutions:

DNS Spoofing: discovery could be intercepted, leading to MitM attack on metadata exchange

Is this unique to OpenID? No, not really, but because OpenID is so dynamic, the DNS threat is more serious for OpenID than for other systems that rely on DPS. 1. Use HTTPS. This is a best practice; see GSA document (link?) 2. Use signed XRD? Working group looking into it. 3. We should make a security upgrade recommendation to the spec. ? Web defacing/social engineering: a not-sufficiently-diligent RP could be fooled into following a bogus claimed ID link.

Can be difficult to detect. The metadata is invisible, and an attacker that has taken control of the webserver can use cloaking to only serve up the corrupted content to some parties. 1. Don't allow dynamic metadata negotation? Negates much of what OpenID stands for. 2. Better web security in general. Not really something we can do. 3. Signed XRD? Allows dynamic discovery but prevents casual defacing. Reduces to a previously-solved problem (trust framework for XRD distribution), but it is a hard previously-solved problem. There is nothing in the spec right now about trust frameworks.

If signing is optional, the OP has no way of knowing that security has degraded. Security degrading: An attacker could replace a signed XRD with an unsigned one, or from HTTPS to HTTP, and the OP may not notice. 1. Best practices (again, see GSA document) 2. Library work/better support Session swapping: An attacker causes a user to log into the attacker's account: attacker starts the process, catches the response, and introduces that to the user, so the user signs in as the attacker at some RP.

Attacker can that harvest data from the user, etc.

The RP can't tell which browser the login started from. 1. RP-initiated authentication should use standard XSRF techniques, but there are protocol pieces that could make it better.

Not well specified what should happen to parameters in the return URL: If an OP implements support of the return-to URL, could the attacker not put state into the return URL? Some disagreement here.

2. Introduce some nonce that is in common between the user agent and the RP, and make sure they match? 3. It is believed that there is no way to defeat this attack for unsolicited assertions with the current spec. Login XSRF Similar to session swapping. Threats that derive from a compromised OP: If the OP is evil, it can log in as the user. 1. For Yahoo's proprietary SSO protocols, each RP has a pre-associated user-specific shared secret; if you break into the OP and have access to the OP's database, you can still impersonate. No such defense exists for their OpenID implementation. Open redirector (with checkid_immediate) 1. Best practices Association poisoning: a rogue OP could deliberately cause a handle collision. 1. Spec improvement? Recommendation. RPs do not check to make sure all fields are properly signed. 1. Best practices 2. Audit? test-id.org has many tests (q.v. discussion of trust frameworks)


General Discussion:

Formal threat analysis? Some Stanford grad students did a study: http://www.stanford.edu/class/cs259/projects/cs259-final-newmanb-slingamn/report.pdf

There was a discussion about supporting unsocilicted assertions without enabling session swapping.

The spec is a bit vague on which extension parameters should be signed. The namespaces aren't signed in many cases. Attribute exchange is often not signed.

We need guidelines for what gets signed and what RPs should expect to be signed.


Part 2: HTTP/S Issues

Server conveyance of HTTP policy to client HTTP extensions, in process:

  • Client-security policy
  • Origin header
  • Cross-Origin resource Sharing
  • Content Sniffing
  • Strict Transport Security ("Forced HTTPS")

Client/Browser Issues

1. Stronger transport binding in browser extensions? 

* Holder-of-key in a selector?
  • Access to SSL keying material?
  • Binding of keying material to transport (SRP)?
  • Hard to do on shared hosts - not an issue for secure domains?

2. New client approaches: active selectors?

  • Consistency for user is key
  • OP in a popup box: easy to spoof?

Best practices exist to try to make it better: e.g. address bar must be displayed Do we need a popup phishing blacklist?

  • Run in privileged chrome? e.g. toolbar
  • If the RP could really know what ID to use, the experience could be better/safer, but users don't understand the question
  • How does a selector authenticate to/from the browser extension?

3. Rich Apps and OpenID: We need another session for this.

Retrieved from "https://iiw.idcommons.net/index.php?title=OpenID_Security_Issues:_Protocol_and_Browser&oldid=3463"