22

The Open ID spec requires that relying parties differentiate between HTTP and HTTPS URLs:

11.5.2. HTTP and HTTPS URL Identifiers

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

But StackExchange (et al) strips the URL provided down to the base domain, dropping the scheme, thereby allowing either HTTP or HTTPS to be used. This leaves the user open to MITM attack, with no recourse, per Isn't OpenID over HTTP (not HTTPS) fatally flawed when delegates are used? as noted by this answer.

This is especially true for users using OpenID delegates.

When is StackExchange inc. planning to address this issue?

There's No Mitigation

Now, if it were merely a matter of me always using HTTPS I wouldn't care so much, but my doing so does not avoid the risk (as a matter of fact, my website only responds for the OpenID delegate over HTTPS).

Unfortunately, by their refusal to correct this security flaw, SE leaves me perpetually vulnerable to an MITM hijacking of my account at any time because they will make the request using HTTP if that's what the attacker types into the login field.

And contrary to claims that it's doesn't really matter, "it's only your SE account(s)", it does matter to me - someone could do a significant amount of damage to me in my professional community by taking over my SE account, some of which could never be reversed no matter what moderation capabilities there are (because the damage is done in the minds and perceptions that other people acquire of me as a result of the malicious activity).

Improve this question
18
  • Incidentally, Data Explorer offers this as a profile option... whistles I still maintain that while this is a concern, it's not a particularly large one. Being able to sniff the traffic between the SE server and the OpenID endpoint requires far more access than being able to sniff traffic between the client and the SE server (until HTTPS is enabled by default everywhere)
    – Tim Stone
    Nov 6, 2013 at 15:44
  • 2
    No this is not a duplicate to my old and still unanswered request. It has since come to light that SO violates the requirements of the OpenID spec and I'm specifically requesting that it be addressed and asking when that's likely to happen.
    – Lawrence Dol
    Nov 6, 2013 at 15:45
  • 2
    I mentioned that in a comment there already. This question is asking for them to follow through with fixing this, which is the same thing the other one asks for. The fact that they haven't isn't really reason to post about it again.
    – Tim Stone
    Nov 6, 2013 at 15:47
  • @Tim: Well, the end-points (plural, not singular) are any of a myriad of OpenID providers as well as the web sites of anyone using delegation. That means I am vulnerable to all employees of Google, their ISP, my ISP and my company. That's a lot of people to trust with my SO accounts.
    – Lawrence Dol
    Nov 6, 2013 at 15:47
  • Right, which is why I agree it's absolutely an issue. :) But in that scenario you're already "trusting" the malicious party to perform some service, it's not some random external threat that you don't have advance knowledge of. Mitigating the damage they can do regardless is certainly important, though.
    – Tim Stone
    Nov 6, 2013 at 15:50
  • @Tim: Right; the request to Google is HTTPS requiring me to trust only the Google staff responsible for their OpenID provider; but that still leaves me vulnerable to SO's ISP, my ISP (and, of course anyone inbetween) and my company's staff because the request from SO to my web server is not secured.
    – Lawrence Dol
    Nov 6, 2013 at 15:52
  • Also, this is a bug report, not a feature request, because SO is in violation of the authentication specification.
    – Lawrence Dol
    Nov 6, 2013 at 15:55
  • Sure, I just think it's more important to focus energy on securing the client-server connection first (which is starting to wrap up, from the sound of it), since that's a bit easier to sniff. Securing the OpenID process doesn't do a lot of good if someone can just snatch your authentication information after the fact.
    – Tim Stone
    Nov 6, 2013 at 15:56
  • 1
    You can edit the other report to include the information about the spec violation.
    – Adam Lear StaffMod
    Nov 6, 2013 at 16:40
  • 2
    @Tim: Except correcting this OpenID violation is probably as trivial as storing the entire URL supplied by the user, instead of doing extra work to strip it of it's scheme. Important trivial tasks should not be delayed by slightly more important highly complex tasks.
    – Lawrence Dol
    Nov 6, 2013 at 18:09
  • 2
    The current behaviour exists to prevent unintentional account duplication (reducing account merge inconvenience at the cost of security), so while fixing just the spec violation is fairly trivial, there's much more work in being able to fulfill the goal of the violation without compromising security.
    – Tim Stone
    Nov 7, 2013 at 2:58
  • @Tim: Stripping down the down the domain is just wrong; www.softwaremonkey.org is not the same network name as softwaremonkey.org. Discounting the HTTPS solely for the purpose of finding a matching account when associating would be acceptable, provided what is stored and used by SO is the full URL supplied by the user when the account was associated.
    – Lawrence Dol
    Nov 7, 2013 at 17:45
  • I obviously had nothing to do with that decision, so I happen to agree with you. I'm not defending what they've done so much as providing explanation for why the scenario they've created will require some effort to correct effectively.
    – Tim Stone
    Nov 7, 2013 at 18:10
  • 2
    @SoftwareMonkey That last comment is a very bad example to state your point - in fact it's just plain wrong. We specifically strip www. and only when it's exactly a third level domain. If you have one instance where www.domain.com and domain.com are OpenID providers and go to separate locations I'm all ears - but we have yet to see this. If your argument is someone can steal the DNS, they've already done that with the domain itself.
    – Nick Craver
    Nov 9, 2013 at 20:41
  • 2
    I'd reject http on new accounts.
    – CodesInChaos
    Nov 10, 2013 at 11:17

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .