The association of an OpenID with the relying part must store the scheme used (OpenID spec 11.5.2):

11.5.2. HTTP and HTTPS URL Identifiers

Relying Parties MUST differentiate between URL Identifiers that have different schemes.

However StackExchange strips the scheme from the URL and stores only the base domain name. Thus if I provide a URL of https://www.mywebsite.com/... StackExchange associates only mywebsite.com/.... This is wrong on two counts, the lost scheme and the stripping of the subdomain (www).

Logins shown by Stack Exchange

Since StackExchange is then prepared to make the initial relying request using HTTP, the login is subject to having the response altered, allowing an attacker to substitute their own response, for example altering the response to delegate to a provider of their choosing:

<link rel="openid.server"   href="https://www.myopenid.com/server">
<link rel="openid.delegate" href="https://xxx.myopenid.com/">

In addition, failure to clearly and visibly use HTTPS for the authentication form is a major fail on the part of the StackExchange network (see this question).

And, of course, the authentication cookie is vulnerable to sniffing and session hijacking, a weakness that's been known for years.

To mitigate these problems I request that:

  1. Stack Exchange stores the entire URL provided in the login form.
  2. The login form be changed to permit the browser to store and autofill previous values for the manual OpenID field so that I don't have to type the entire URL every time I login. (done)
  3. That Stack Exchange run parallel HTTPS support for the entire network so that security aware users can avail themselves of it.
  • 1
    Related – Rory Aug 10 '12 at 22:25
  • 1
    This requires the attacker to be MITM between the server and the claim endpoint during discovery though, which is relatively non-trivial. It's far easier to sit between the server and the client and just steal their authentication cookies. – Tim Stone Aug 10 '12 at 23:33
  • 3
    @Tim: Just because there's another attack vector doesn't mean that this one should not be fixed. But you're quite correct, StackExchange, being an authenticated resource, should allow us to use TLS while authenticated. – Lawrence Dol Aug 10 '12 at 23:37
  • My point was that it's very unlikely that someone could carry out this exploit, because it requires the attacker to be able to modify the traffic between the two servers. This isn't impossible, certainly, but it's unlikely to happen here given the low value of the target. While DotNetOpenAuth does have a setting to require HTTPS for discovery, note that prefixing a schemeless identifier with http:// is required by the OpenID specification. – Tim Stone Aug 10 '12 at 23:59
  • @Tim: You are correct - I am staggered. That means I am stuck explicitly specifying the https:// for every OpenID site I use. And if SO is any indication, associating only the domain and not the scheme, I am forever vulnerable to an intercept as above, even if the relying site does correctly use TLS for all authenticated traffic. This seems like a huge blunder by someone somewhere, to me. – Lawrence Dol Aug 11 '12 at 0:24
  • Yeah, the scheme isn't supposed to be normalised to http:// in the case that https:// is provided - the relying party should consider them separate. If this is the current behaviour it's actually taking away some control of security from the user in favour of what I assume to be convenience, and I'd agree that's not a good thing. – Tim Stone Aug 11 '12 at 0:34
  • 3
    This is related to the discussion on security.SE, which revealed that an attacker does not need to do a MITM, but passive sniffing at a time of his choice is sufficient. – Hendrik Brummermann Aug 11 '12 at 18:15
  • Theoretically, the https and the http versions could return completely different content, and could, indeed, be completely separate OpenIDs. Unlikely, but possible. – TRiG Nov 6 '13 at 19:33

You must log in to answer this question.

Browse other questions tagged .