3

Why does security.stackexchange.com not encrypt logins?

It kind of seems counter-intuitive.

Is it simply that a legitimate SSL certificate costs money / takes time to maintain?

I would think that unencrypted logins are a bad idea anywhere because people reuse passwords.

1
  • 1
    Are you asking, in general, why would X site not use SSL for the logins, i.e. what reasons are there? Or are you in effect stating that this site should be... if the latter, this should probably be on [meta], though it already was asked, several times I believe.
    – AviD Mod
    Commented Apr 9, 2012 at 13:39

5 Answers 5

Reset to default
8

Security.SE, like all other SE sites, don't actually have a login screen to encrypt.
The "login" screen, such as it is, is really just a referral to your OpenId provider. You submit your password (or any other authentication credential) to them, not the SE site.

That said, SE does have its own OpenId provider, and I believe that the actual authentication process is encrypted over HTTPS. It works just like any other potential provider, and simply redirects back to the SE site.

In general, implementing HTTPS for a high-traffic site is always a trade-off, even if it usually is a tradeoff that makes sense.
You can find some additional aspects here - What are the pros and cons of site wide SSL (https)?

Specifically regarding this site (should be on meta), there is some context in Are there plans to support https?.
Even more context for this site - and many issues that apply to the general case - here: Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?

5
  • Although the SE OpenID provider is using HTTPS, it hides it, which is bad (or makes it pointless).
    – Bruno
    Commented Apr 9, 2012 at 13:59
  • @Bruno that's interesting, I was not aware of that since I dont use the SE provider. Have they already been made aware that this is a flaw?
    – AviD Mod
    Commented Apr 9, 2012 at 18:13
  • I hadn't thought about it, but that's a good point, I've just reported it on the main meta, just in case. I don't use it either, so I hadn't noticed until I looked at it when writing my answer.
    – Bruno
    Commented Apr 9, 2012 at 18:23
  • But don't forget, Jeff recently changed his mind about this.
    – Major Major
    Commented Apr 22, 2012 at 19:08
  • @OldPro -ish. He agrees in principle, sometime in the near future, etc. Besides, he's no longer in charge, anwyay :)
    – AviD Mod
    Commented Apr 22, 2012 at 19:56
3

Regarding the login process itself, there are a couple of issues:

  • If you use an external OpenID provider (e.g. Google), whether-or-not HTTPS is used will depend on the provider. The four providers with a big icon (Google, Yahoo, MyOpenID and Facebook) use HTTPS pages.
  • If you use the StackExchange login, it's also using HTTPS, but via asynchronous calls, within a div/iframe, which is useless (as detailed here), since the user has no way of verifying that it is using HTTPS indeed. That's quite bad actually (or pointless).

As a general rule, when using HTTPS: always make this clear to the user, so that the user can check (a) that HTTPS is used and (b) that it is used with the site they expect (I've used Chrome's developer tools to find out that it was making HTTPS requests via asynchronous requests, not something that most users would do). This means that the main URL in the browser should be using https:// and the domain should be the one relevant for that particular part of the process. A bad example of this second point is 3-D secure, whereby the bank's address is often embedded on the page, still using the merchant's address in the top bar.

In addition, ideally, there should be support for HTTPS over the entire site. This request has been made a number of times on Meta, but it was turned down after a risk/cost assessment exercise. Maybe it will be re-evaluated in the future.

2

Security.stackexchange runs on the stackexchange sites which all use the same settings.

If you use google/yahoo/openID/facebook for your login/password then it is sent over SSL. If you login with "Stack Exchange" its sent over the network in plaintext (bad). It would be nice if they let you choose to go to an https site, or at the very least had an option to only send/receive secure cookies for an account (SSL only) to eliminate firesheep style attacks; but they don't. The stated reason is extra CPU cost for millions of monthly visitors. Its a free service and widespread impersonation due to stolen cookies doesn't seem to have become a problem, yet.

2
  • They do let you choose to go to an HTTPS site. You should be able to type in your SE OpenID URL using https explicitly.
    – Bruno
    Commented Apr 9, 2012 at 14:01
  • @Bruno -Nevermind - just saw your link in your answer stackoverflow.com/a/3183176/372643 and looked at the source of the login page in more detail. As you have no assurance that you aren't in a MITM attack. My point for the HTTPS site was for the entire site (so no eavesdroppers). I wasn't aware originally that they use ajax to do cheap https for 'login via stack exchange' (which I never have used).
    – dr jimbob
    Commented Apr 10, 2012 at 14:59
0

I think it does use SSL for login the process. It's using openID which itself is using SSL if I'm not mistaking.

1
  • If your OID provider doesn't spec SSL then it's not used. OID is secure anyway.
    – Chris S
    Commented May 1, 2012 at 15:44
-2

First (and I can't believe a Security site hasn't mentioned this yet), there's more than one way to secure a login. SSL/TLS is not the option option. The other options are perfectly valid too.

Your password is sent to your OpenID Provider. Most use SSL to secure the connection because so many people are under the false pretense that this is the only way to secure communication on the Internet.

I run my own OpenID Provider and actually use HTTP Digest Auth to secure the password process, not SSL (though SSL does work, it's not enabled by default). It's based on MD5 (and I'll preempt anyone who think MD5 is 'easy' to crack by saying that in 2006 researchers thought they were close to cracking it; 6 years later still nothing but brute force).

Your login likely is encrypted, just not with SSL, which as you have learned isn't the only way to do it.

10
  • 4
    Your scheme is pretty weak 1) Steal the session-id 2) use an active attack that replaces the digest auth with a basic auth. Not many users would notice. 3) An offline dictionary/brute-force attack against plain md5 is pretty damn fast. Few users use a password with 60 bit or so entropy, so this is a real danger. 4) Server needs to store a badly hashed password, instead of well hashed password using PBKDF2 or bcrypt.
    – CodesInChaos
    Commented May 1, 2012 at 18:56
  • 1) session-id is linked to IP; if you can spoof my IP you're close enough that SE is the least of my worries. 2) MITM like that is nigh impossible to pull off without direct access to the network at either end, see #1. 3) Dictionary attacks might be fast by your standards, but it'd take either months of Tesla or EC2 time to crack a HTTP Digest, if you're willing to put those kind of resources into it, I've got bigger problems. 4) Unlike most people, I do pay attention to security, my server is extremely secure and you're welcome to test that. While you have valid points, they're pretty minor.
    – Chris S
    Commented May 1, 2012 at 22:28
  • 1
    Any scheme is secure in the absence of attackers...
    – CodesInChaos
    Commented May 1, 2012 at 22:55
  • 1
    There are a number of problems with HTTP Digest: no protection of the request/response entities, hard to distinguish from HTTP Basic from a UI point of view, downgradable to HTTP Basic, and also it doesn't really help proving the identity of the site you're visiting. It may work for you because you probably know what to look for (and you'd just be protecting your password at best). In general, normal people expect form-based logins nowadays anyway: HTTP Basic/Digest are out purely from a look&feel point of view. In that context HTTPS is required.
    – Bruno
    Commented May 1, 2012 at 23:25
  • @CodeInChaos xkcd.com/538 The point of security is not to keep attackers out under all circumstances. The point of security is to make a reasonable assurance of attack prevention.
    – Chris S
    Commented May 2, 2012 at 0:45
  • @Bruno You're making the false assumption that I'm using the browser's built-in client instead of a JavaScript backed Form and CGI script to handle the authentication on the server end. It's really quite nice looking and explicitly states what autnetication type I'm using. The user doesn't even have to understand what "digest" is, the Form explains that the login is secured. This doesn't provide server authentication, but that's not SE's problem and can't be solved by them in a OID configuration anyway.
    – Chris S
    Commented May 2, 2012 at 0:59
  • @ChrisS, OK, so you have a form on your web-page that asks you for your password. How do you know it really is your page and that someone hasn't tampered with the script to grab your password and downgrade or send it somewhere else? Do you check the source code every time? "the Form explains that the login is secured": it's secure because the web page says it is?
    – Bruno
    Commented May 2, 2012 at 1:03
  • @Bruno How could any OpenID Consumer possibly verify that the webpage people are logging in at is valid? Critiquing my personal OpenID Provider setup has nothing to do with Stack Exchange. As a side point, "the web page says it is" <-- Yeah, that's good enough for most people, right or wrong. Your browser says your bank's SSL Cert is valid, have you check the browser's source code lately?
    – Chris S
    Commented May 2, 2012 at 1:05
  • The problem with this question is mostly about SE's own OpenID provider: meta.stackexchange.com/questions/128733/…
    – Bruno
    Commented May 2, 2012 at 1:09
  • There's always a leap of faith regarding SSL certs (and what verifies them). The problem with your approach is that, even with software you trust, there could be a MITM on your network altering the connection, more plausible than altering the browser.
    – Bruno
    Commented May 2, 2012 at 1:12

You must log in to answer this question.

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