2

Does Stack Overflow use SSL when transmitting passwords during the log-in process? This question comes up when you log-on, because there is no green lock in the browser when logging in.

I do use the Stack Exchange OpenID provider and my browser stays on that page during the log-in process and hence the connection seemingly stays insecure, because there is no green browser lock.

StackLogIn1

Edit:

I had a look now into the network stream and saw there is indeed a https connection taking place to Stack Exchange after having entered my credentials.

However the common Web user won't do a network trace each time when he enters credentials into a HTML form on the Web. Therefore not seeing a green browser lock nor being able to verify the certificate should ring alarm bells and could be considered a problem at least from an UX point of view. I do not find this behaviour to be optimal.

StackLogin2

Improve this question
10
  • 4
    Stack Overflow doesn't transmit any passwords. Do you mean the Stack Exchange OpenId provider? What provider do you use to log in with? – Martijn Pieters Oct 22 '13 at 6:53
  • 7
    If you are going to make such strong claims, then there should be at least some evidence aside from just statements. – Travis J Oct 22 '13 at 6:54
  • 2
    @Travis J: Ostensibly, the strong claims would "speak for themselves". – BoltClock's a Unicorn Oct 22 '13 at 7:22
  • 1
    I didn't understand this sentence: how can I now respond to you, my rep has fallen below 100. – Himanshu Jansari Oct 22 '13 at 7:32
  • 2
    Who said you can not reply to posts if your reputation has fallen below 100 on MSO? You can always reply if it is your post. And you need only 1 reputation on Meta to post a comment. – Himanshu Jansari Oct 22 '13 at 7:35
  • 3
    You see, if you would look into your network stream first, you would avoid downvotes (or at least some part of them). "Research first" works on meta, too. – Mołot Oct 22 '13 at 7:37
  • 1
    Strange could not reply before. Anyway I edited the post now. You can now answer my question and take back your downvotes. Appreciate it! – user233836 Oct 22 '13 at 7:39
  • An active attacker can trivially break Stackoverflow + Stackexchange-OpenID by running SslStrip. – CodesInChaos Oct 22 '13 at 9:17
  • @codesinchaos, While it is true that a login session without a browser lock icon makes you more vulnerable loosing your credentials to a local MITM attack on your LAN; that technically is not Stack Exchange's problem. That is a security problem on your LAN... either within your home, or inside your company. If Stack Exchange wants to be the best possible site, I think adding SSL everywhere would be a security improvement... – Mike Pennington Oct 22 '13 at 15:42
  • The login process is under review and planned for changes anyway... – Marc Gravell♦ Oct 23 '13 at 11:21
9

Therefore not seeing a green browser lock nor being able to verify the certificate should ring alarm bells and could be considered a problem at least from an UX point of view.

It's a fair point that people feel more comfortable when they see a lock icon or the big browser bar while logging into a site. For the MITM attack reasons mentioned by CodesInChaos below1, SSL everywhere provides the most protection for your login session and I can only speculate about why Stack Exchange doesn't use SSL to encrypt all pages (although there is an obvious economic issue to consider). See Nick Craver's blog entry about the issues around enabling SSL on Stack Overflow

In general, stack exchange caters to a rather technical audience; it's not uncommon for users to check behind the curtains when they have a concern. However, Stack Exchange is certainly not the only big site on the internet without a browser lock icon during the login process. Also, this question will be a useful point of reference for anyone worried about the issue going forward.

Does Stackoverflow use SSL when transmitting passwords during the log-in process? There is no green lock in the browser when logging in.

While I can understand the fear you may feel in light of recent news, there are more sophisticated tools than the Firefox browser bar to validate whether a site is using SSL. One such tool is fiddler, or you can use wireshark if you prefer sniffing the directly.

These days HTML pages are complex, and unless you're going to an internet banking site (which depends on marketing trust), there is no guarantee that a plain browser icon means the authentication is not encrypted.

Fiddler / wireshark will capture everything your browser sends.

whole fiddler window

I use stack exchange's OpenID, and captured my HTTP and HTTPS sessions in fiddler. As you can see below, the authentication portions are using SSL.

zoom in on authentication

I would also mention that SSL itself is no panacea, and there are some rather disturbing things that have happened with regard to root CAs being hacked and the general state of so many certificates being trusted by default.

Replicating the login UX flow...

As a side note, Martin obviously was able to see a browser lock when he was logging in, but when I go through this sequence, I see what Mad Scientist mentioned...

A) Go to stackoverflow.com

home page

B) Select Stack Exchange's OpenID

openid provider selection

C) Login form

brower login form

Footnotes:

1 While it is true that a login session without a browser lock icon makes you more vulnerable loosing your credentials to a local MITM attack on your LAN; that technically is not Stack Exchange's problem. That is a security problem on your LAN... either within your home, or inside your company. If Stack Exchange wants to be the best possible site, I think adding SSL everywhere would be a security improvement... Although it's again worth mentioning that SSL itself isn't a panacea.

Improve this answer
7
  • Try using Fiddler on Linux and you would probably would have gone with the Firefox Dev tool as well for ease of use. (and if you must know I also used tcpdump to verify) – user233836 Oct 22 '13 at 8:29
  • 1
    Unless you check that the iframe is loaded using SSL, on every single login, an attacker can simply run SslStrip without you noticing. Checking for https in the url bar is much less work than checking with Firebug etc. each time. – CodesInChaos Oct 22 '13 at 9:19
  • @CodesInChaos, I agree that you get the most security from using SSL everywhere. It's also true that MITM tools like that exist, and the reason they work so well is because most people routinely don't bother checking for SSL. Side note: if I understand the open-id auth sequence correctly, after you have authenticated your session through openid you get the auth-token cookie stored in your brower. Unless SE uses SSL on all pages (which may not be something they're willing to take on), the attacker could run sslstrip and grab that auth token un-noticed as well. – Mike Pennington Oct 22 '13 at 9:38
  • The token is only valid for stackoverflow, the password is valid for all sites where stackexchange openid was used (and probably even more). – CodesInChaos Oct 22 '13 at 9:40
  • @CodesInChaos, regarding the password issue, that's why said that I agree that SSL everywhere is better. You mentioned ssl loaded in an iframe above, I ran fiddler against my login session and couldn't find one... do you have a hyperlink to the part of the process that is using SSL in an iframe? – Mike Pennington Oct 22 '13 at 9:47
  • I didn't check recently, but AFAIR a SE dev said they were using an https iframe on a similar question. – CodesInChaos Oct 22 '13 at 9:48
  • Well done screenshotting the UX flow, that's what I was talking about. At first glance you will think the site is insecure. This is in contradiction to when you change your password in the respective StackOverflow Settings Tab, the Browser visually switches to SSL, indicated by displaying a secure connection in the URL bar (green lock etc). – user233836 Oct 22 '13 at 9:49
2

You are already logged in to your OpenID provider. You are not entering your password.

You never see the green lock, because you never loaded a full page over SSL; instead, clicking the provider button issued a redirect, and you were automatically re-authorized, because you already have logged in to your OpenID provider.

If you were to log out from your StackExchange OpenID profile (click the logout link on that page), then log in again, you would be using HTTPS connections all the way:

login screet

The only place where you'd not see a green lock and are asked to log in, is when you use the 'log in' link from Stack Overflow when not logged into your OpenID, and select the Stack Exchange OpenID provider:

OpenID choices

You are presented with a SSL iframe:

Login without padlock

This is confusing. All the other OpenID providers are redirects, and you have a point that that is not sending the right signal about security. A redirect instead of an iframe would perhaps be a better choice there.

That said, the whole Stack Exchange network will start to support full-on SSL Real Soon Now™ (in 6-8 weeks, I'd say), which should mitigate this issue.

Improve this answer
6
  • 1
    Hmm, when I try this with an incognito browser sesssion, the page is still only http and not https. The page also looks different than your screenshot – Mad Scientist Oct 22 '13 at 8:54
  • Sometimes it asks you for the password having http in the url, embedding a https iframe, sometimes its https all the way. – CodesInChaos Oct 22 '13 at 9:21
  • @CodesInChaos: ah, when using 'login' on Stack Overflow, then clicking 'Stack Exchange' for the Open ID provider, then yes, it uses an iframe. – Martijn Pieters Oct 22 '13 at 9:45
  • Just use a fresh Browser Session (Cookies, Cache, etc deleted) and you will not be logged on already. – user233836 Oct 22 '13 at 9:51
  • 2
    To confirm: yes, the iframe should be disappearing "Real Soon Now™" – Marc Gravell♦ Oct 22 '13 at 11:08
  • 2
    @MarcGravell: In 6 to 8 weeks? – Martijn Pieters Oct 22 '13 at 11:10