17

As a site dedicated to IT Security, we commonly find ourselves preaching about things like HTTPS, salted and hashed passwords, and such. However our own website is in violation of some of the security standards we so vehemently profess.

One particularly glaring example is the lack of proper HTTPS support on the IT Security StackExchange site and blog. For the main and meta site, some of this is mitigated by the availability of third-party OpenID providers who do use HTTPS. However, this is not an option for the blog's administrative interface where in-the-clear HTTP appears to be the only way to connect. Users who choose to create a StackExchange account with StackExchange's OpenID provider are also left to presume they are sending their credentials over clear HTTP.

EDIT: Bruno has pointed out that StackExchange's OpenID provider actually does use HTTPS, but it's not done in a way that will be apparent to most end-users. Also, there's no way to validate the presence or authenticity of that function without reviewing the login page code every time.

Stack Overflow Meta - StackExchange OpenID provider should clearly use HTTPS.

This particular example is, I'm sure, just one among several issues that could affect our security as users of the StackExchange network. These same issues could also impact our reputation and credibility as an IT Security community.

StackExchange has already had at least one major security compromise, as Jeff confessed to in a couple blog entries:

There are also several security-relevant suggestions (below are just a few) on Meta which have either been deferred, declined, or in some other way seem to be brushed aside.

While there may be some logical business reasons for not implementing these requests (or not implementing them "properly"), I'd like to think there's also something we could do about it. We are a community of IT Security professionals - engineers, programmers, auditors, pentesters. Surely among us we could find some way to help better secure StackExchange.

There may be some particular knowledge or work resource that SEI lacks, which someone here could volunteer or offer at a discount. Or, maybe someone here with a security-focused mind and a wealth of experience-based technical knowledge could volunteer their time to consult with an open ear at SEI who could make some changes.

I really don't know what it will take or what SEI might accept, and maybe this is just a pipe dream, but I know we've got a lot of resources in this community and there's got to be something we can do to help. What kind of ideas do you have?

10
  • Actually, the StackExchange OpenID provider should still send credentials over HTTPS in the iframe... when you known there's no MITM. The problem is that there is no way to know whether this is the case, and that should be fixed. (More details in this question following a question here.)
    – Bruno
    Commented Jun 27, 2012 at 18:06
  • @Bruno Thanks for pointing that out. I feel slightly more comfortable knowing this, but only just so.
    – Iszi
    Commented Jun 27, 2012 at 18:15
  • @Bruno - any network inspection panel in the browser will confirm this is the case...I don't follow the "no way to know", are you referring to another aspect of the transmission?
    – Nick Craver Mod
    Commented Jun 28, 2012 at 23:17
  • @NickCraver Firstly, you can't expect the average user to go through the developers tools; the network inspection happens too late anyway (once the damage may be done), what you'd need is to look at the code and the DOM. Secondly, if there's a MITM, some other code could be injected, you can't expect even experienced developers to go through the all the code that's pulled to check it doesn't do anything subtle with the DOM in addition to what you'd initially see.
    – Bruno
    Commented Jun 28, 2012 at 23:21
  • @Bruno - ...what way could you prove it's HTTPS to the average user? I can't think of a way we'd demonstrate this, short of the whole login page being HTTPS, that's a much larger problem (see my answer below). The most important thing to us is that it is HTTPS, and that's the current case.
    – Nick Craver Mod
    Commented Jun 28, 2012 at 23:26
  • 2
    @NickCraver Browsers have visual clues specifically designed for pointing out it's HTTPS (lock/blue bar/green bar/https:// clearly visible): that's what users should look for. GUI interaction is essential to the overall security of using HTTPS. Saying "it's using HTTPS anyway" (... when you know there's no MITM) just isn't enough. See OWASP TLS Secure Server Design rule #1 ("landing page").
    – Bruno
    Commented Jun 28, 2012 at 23:29
  • @Bruno - that requires the entire page be over HTTPS (which we're moving to, again: see my answer below, it's not an easy thing to do)...short of that we can't trigger such visual any styling a user's browser may have for HTTPS.
    – Nick Craver Mod
    Commented Jun 28, 2012 at 23:31
  • 1
    @NickCraver, yes, the entire page. The problem here is that not only some pages are not over HTTPS, but the login page itself isn't. SE could at least have its entire OpenID login page server completely over HTTPS: instead of embedding the login in an iframe on the same page when clicking on the SE login logo from http://stackoverflow.com/users/login, there could be a full redirection to https://openid.stackexchange.com (in the same way as it redirects to the others), so that the user can see where they're actually typing their username/password. That can't be hard to do.
    – Bruno
    Commented Jun 28, 2012 at 23:36
  • 1
    @Bruno - no, it isn't hard, but it greatly degrades the login experience for those using it, so you can't say it's a totally positive tradeoff. Given that we plan to have the login page itself be SSL, changing user behavior to be a redirect then back isn't something we want to do. You have to remember security by itself, while always a concern, isn't the only concern and factor in all decisions.
    – Nick Craver Mod
    Commented Jun 28, 2012 at 23:41
  • 3
    "Greatly degrades", compared to what's done for all the other OpenID providers with their icons on that page? In times where public Wifis are commonly used, protecting user password properly should matter a bit more. The degradation of login experience is quite minor in this case. The page at openid.stackexchange.com could be made a bit prettier than it is if that matters. This would make sense.
    – Bruno
    Commented Jun 28, 2012 at 23:44

3 Answers 3

Reset to default
14

A slight update from the Stack Exchange engineering side of things, since it's been a while:

We are moving towards HTTPS for everything that needs to be secured (whether it's just for logging in and logged in users or everything is yet to be decided). The issue here is a few fold: to start with, we would need certs with our current scheme, a lot of certs with no end in sight with the current scheme. Let's take a look at why:

  • security.stackexchange.com - ok good, *.stackexchange.com wildcard cert (we have this)
  • meta.security.stackexchange.com - uh oh, wildcards don't go 2 levels deep, we'd have to make a major change (likey) to how metas work (and share cookies) here.

For n sites (and growing), having the child metas requiring another cert (or an entry/update on a shared cert, more likely) is a maintenance nightmare. Also, each meta would now need its own DNS separate from the parent site as we create them, to point at that multi-cert endpoint (remember, a wildcard can't be a member of a multi-domain cert, at least not in a way accepted by most browsers).

You can see how our maintenance goes way up when adding a site, and it's a lot more configuration to keep around - since we're in the middle of the following:

  • Moving to new load balancers
  • Setting up a redundant data center (Oregon)
  • Moving our primary data center (in New York)
  • Moving our databases to a set of SQL Server 2012 clusters (weeeeee)
  • About to start a major code initiative (that'll take months)
  • Setting up a new office
  • Planning another office move
  • plus anything that comes up day to day

...now's not the best time for us to take SSL on as well. The most critical bits are already travelling over SSL, so while we're moving towards expanding that support, we're not there quite yet.

For the inevitable "what if someone gets a developer cookie??" argument...that's why we use the sites over a secure VPN while travelling where a MITM attack is a significant risk. I'd be happy to expand on this more if there are further questions, just wanted to let you know we're not ignoring it or brushing it aside...we're just extraordinarily busy as of late.

13
  • 2
    Since meta.*.stackexchange.com is an issue for the certificates, perhaps the meta sites could be moved to *.stackexchange.com/meta/.
    – Bruno
    Commented Jun 28, 2012 at 23:53
  • 4
    @Bruno - my arms aren't long enough to indicate just how major a change that would be to how the sites function. Host is god for literally everything around data access.
    – Kevin Montrose
    Commented Jun 29, 2012 at 0:52
  • 1
    @KevinMontrose fair enough, another convention like meta-security.stackexchange.com (and so on) perhaps?
    – Bruno
    Commented Jun 29, 2012 at 0:57
  • @Bruno - that's more likely, though we'll have to address some cookie issues and change the way login fundamentally works for metas (or possibly the way all logins work)...we haven't locked down exactly what approach we'll take here just yet.
    – Nick Craver Mod
    Commented Jun 29, 2012 at 0:59
  • 1
    @Bruno yeah, something like that. As the person who's actually sent some significant traffic over our budding HTTPS infrastructure (API V2 and global auth), let me say it's kind of hilarious just how resource intensive it is compared to HTTP. When people say "SSL isn't that expensive anymore" what they're really saying is "supporting HTTPS isn't a joke you tell at conventions any longer"; it's still months of planning and execution at our scale, and naturally it goes on top of all the other stuff we've gotta do.
    – Kevin Montrose
    Commented Jun 29, 2012 at 1:03
  • 4
    @KevinMontrose there are few reports of large scale HTTP->HTTPS switches besides this one from Google. It would be good to blog about your experience, if you find the time :-)
    – Bruno
    Commented Jun 29, 2012 at 1:09
  • 3
    @Bruno - oh, we'll definitely have a retrospective; it'll probably come from the Sysadmins on blog.serverfault. Still a waaaaays out though; we literally have to build out additional data centers before then.
    – Kevin Montrose
    Commented Jun 29, 2012 at 1:11
  • 1
    The idea of managing all of those certs does seem daunting, but so long as you pick a good vendor with reasonable tools it's not actually that much work to manage a few hundred certs with a team of Kyle's size. Particularly with the extra manpower when Bart starts.
    – Scott Pack
    Commented Jun 29, 2012 at 13:00
  • @ScottPack - I agree on the cert part, but it's not just the certs, it's the IPs those certs are tied to (if we're dealing with a wildcard/multi-domain combo). Since we're moving towards an active/active load balancer setup and each of those certs has a minimum of two addresses that need to be kept up with, that's where it gets more fun. Certs and getting them is relatively easy and cheap, it's the management of everything else around it that starts to add up.
    – Nick Craver Mod
    Commented Jun 29, 2012 at 13:47
  • @NickCraver I know, what do you think I was referring to?
    – Scott Pack
    Commented Jun 29, 2012 at 13:48
  • @ScottPack - the actual cert procurement, since that's the only phase in which the vendor matters much. We have larger plans for all of this that haven't been totally laid out yet or posted in this answer (multiple data centers), so designing for the least-manpower needed (even if we currently have that manpower, but still secure) is absolutely what we're after.
    – Nick Craver Mod
    Commented Jun 29, 2012 at 13:50
  • @NickCraver Sure, most of that falls directly into your configuration management system, which I obviously can't really speak to. Bringing up the vendors was more about managing the life-cycle of the certs themselves. Some vendors, like InCommon, have pretty fantastic tools for that process.
    – Scott Pack
    Commented Jun 29, 2012 at 14:06
  • @ScottPack - I'll put a note to ask here about best places for certs, people with actual experience against particular vendors is an excellent way to see what'll work well for us. I don't know of problems with our current vendor, but if we're managing many more certs (or multi-domain ones) that's just a whole different scenario that may prompt a vendor switch. Configuration we have full history, syncing, etc...but different data centers are going to have different IPs, so the lack of sync still adds a fair bit if complication, not sure we can do anything to cut that out completely.
    – Nick Craver Mod
    Commented Jun 29, 2012 at 14:13
3

To be honest, I think there is mileage in the SEI devs tapping into the collective experience here for guidance. We have individuals who have been heavily involved in aspects of security in networks, policies, testing, architecture etc from small companies to global banks.

I'm guessing from @Nick's comments that that may be a long term relationship, as there are a wide range of priorities in growing at the rate the SE network has been, but I would like to stress to @Nick and the rest of the devs - if you do want to sound out security ideas, and practical ways round seemingly unsurmountable blocks, security.stackexchange.com is a great place to come for answers :-)

-3

It would be nice to see a statement or even proof that password hashing is being done properly.

Unfortunately, I don't have any ideas on how to provide this kind of proof without lowering the amount of security in the system. (Such as displaying your password hash on your profile page when you are logged in... but not over SSL. Clearly reduces security.) A statement in the privacy policy along the lines of "We use bcrypt to hash your passwords." would be a good step.

In fact, it would be nice to see that on every site that takes passwords, not just StackExchange. All we have currently is the plain text offenders site.

4
  • 12
    The only passwords we store are for the OpenID provider itself, and you don't have to take our word for it...it's open source, you can just look at the code: code.google.com/p/stackid/source/browse Also, I can confirm the keys are stored in a very secure place on our network (even I can't see them)
    – Nick Craver Mod
    Commented Jun 28, 2012 at 22:58
  • 2
    They are uniquely salted and hashed with pbkdf2 with at least 4000 iterations, last I checked. fyi, lastpass recommends no more than 500 for their own service.
    – David Murdoch
    Commented Jun 29, 2012 at 0:19
  • I should have gone and double-checked before hitting submit. I had a memory of there being a username/password option but my memory was incorrect. Invalid question for StackExchange.
    – Ladadadada
    Commented Jun 29, 2012 at 9:01
  • @Ladadadada - there is one, if you click the StackExchange provider option on login you have a user/pass...but in reality that's just an HTTPS embedded OpenID provider built in-house...the accounts there are not stored on the sites, that's separate and much more secure.
    – Nick Craver Mod
    Commented Jun 29, 2012 at 14:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .