Last modified: 2013-08-28 23:57:56 UTC
With the exception of a few minor bugs (specifically email links), $wgSecureLogin functionality is for the most part complete. Is there any reason HTTPS login has not yet been enabled on enwiki?
(In reply to comment #0) > With the exception of a few minor bugs (specifically email links), > $wgSecureLogin functionality is for the most part complete. Is there any reason > HTTPS login has not yet been enabled on enwiki? Why just enwiki?
I was under the impression that forcing https login is pointless if the user then browses on the insecure site - or am I wrong in that?
@Jarry1250 If the login in is plaintext, then the attacker grabs the victims password and can login at any time (and try to attack other services using the same username and password). If the login is over ssl, and then a user browses in plaintext, the attacker can get the user's session and impersonate the victim, but can't re-login if the session goes away, and can't use the victims password on other sites.
(In reply to comment #1) > (In reply to comment #0) > > With the exception of a few minor bugs (specifically email links), > > $wgSecureLogin functionality is for the most part complete. Is there any reason > > HTTPS login has not yet been enabled on enwiki? > > Why just enwiki? Figured it was a good start. I'm totally open to just enabling it outright on all language Wikipedias (or even all wikis, if that's possible).
IIRC, ops wasn't deeply opposed to the idea of just switching the default to https for all pages, though that would be technically more difficult to get right, I think. Login forcing seems like a good start.
See also bug 29898.
Do I need to make a Gerrit change for this? Or is there some other way we can move forward and do this?
Indeed, a Gerrit change would be nice.
Kk, where exactly would I go about adding the option? If I'm correct, it's somewhere in operations/mediawiki-config (probably in the wmf-config directory), but I have no idea exactly where.
I would put it in wmf-config/CommonSettings.php
https://gerrit.wikimedia.org/r/21322
Finally, do you want to enable it only on en.wiki or Wikimedia-wide?
I'm not sure. How does everybody else feel about it?
My thoughts on this are that: (1) we shouldn't set $wgSecureLogin until there's a user preference for HTTPS (bug 29898) and a cookie to kick users from HTTP back to HTTPS); and (2) we shouldn't set this per-wiki as it's a complete waste of time (we'll end up with a dozen bugs asking for individual wiki changes until someone finally just sets a default; let's just set the default reasonably from the start). I'm strongly inclined to mark this bug as a duplicate of bug 29898. Is there any reason not to?
The two bugs are two separate HTTP/HTTPS behaviors. - bug #29898 offers the user to enforce every page is served in https:// - bug #39380 allows the user to browse in http:// but enforce login in https://
(In reply to comment #14) > My thoughts on this are that: > > (1) we shouldn't set $wgSecureLogin until there's a user preference for HTTPS > (bug 29898) and a cookie to kick users from HTTP back to HTTPS); and I strongly disagree with this. Right now all WMF wikis send all passwords in plaintext over insecure connections. That is a major security vulnerability and I'm surprised we haven't resolved it earlier. Yes, it would be better if EVERYTHING was over TLS, but this is the least we can do to start enforcing a better security policy. > (2) we shouldn't set this per-wiki as it's a complete waste of time (we'll end > up with a dozen bugs asking for individual wiki changes until someone finally > just sets a default; let's just set the default reasonably from the start). I'm totally up for enabling it for all wikis as the default. (In fact, my original patchset in Gerrit did just that by accident.) So that's fine with me as long as nobody else objects.
I agree with Tyler we should enforce security. Furthermore, this becomes a best practice: Google, Yahoo! use this https for login solution.
(In reply to comment #16) > I strongly disagree with this. Right now all WMF wikis send all passwords in > plaintext over insecure connections. That is a major security vulnerability and > I'm surprised we haven't resolved it earlier. All Wikimedia wikis send all passwords in plaintext? :-) And to call this a major security vulnerability is a bit extreme as well. But I agree with your general point about wanting a more secure user experience, which is why I'd rather see effort focused on fixing bug 29898.
(In reply to comment #18) > experience, which is why I'd rather see effort focused on fixing bug 29898. But does this change require any other effort besides the change of an existing setting to true?
(In reply to comment #19) > (In reply to comment #18) >> experience, which is why I'd rather see effort focused on fixing bug 29898. > > But does this change require any other effort besides the change of an existing > setting to true? Err, right. I think I remember what's going on here now. So there's $wgSecureLogin, which basically changes the "log in" link to specify HTTPS. The user clicks "log in" and he or she logs in to HTTPS and the user will stay in HTTPS after successfully logging in. However, when the user clicks one of the million HTTP links (in an e-mail, on a wiki page, on IRC, elsewhere on the Web), the user will not be automagically redirected to HTTPS, he or she will _stay_ at HTTP and he or she won't be logged in any longer. This is very disorienting. The user can click "log in" in the corner of the page, but he or she will be transferred to Special:UserLogin over HTTPS and suddenly the user will appear to be logged in again. In short, the issue with just setting $wgSecureLogin to true is that the user experience kind of sucks, as I understand it. (Feel free to correct me if I've misread the $wgSecureLogin-related code!) (I'm also not sure it actually prevents form submission over HTTP [if the user navigates to the HTTP version of Special:UserLogin directly].) If this is an acceptable situation, it's fine to set $wgSecureLogin to true on Wikimedia wikis. You'll need to get an okay from Wikimedia Foundation operations (ops) first before the change can be deployed. The load spike from logging in over HTTPS should be minimal, but the load spike from users continuing to use HTTPS after logging in will be less negligible, I think. Ops will also wants a heads-up so that there isn't an unexplained load spike.
(In reply to comment #19) > >> experience, which is why I'd rather see effort focused on fixing bug 29898. I don't think they're mutually exclusive. We need to do both. (In reply to comment #20) > In short, the issue with just setting $wgSecureLogin to true is that the user > experience kind of sucks, as I understand it. (Feel free to correct me if I've > misread the $wgSecureLogin-related code!) For any users that notice the protocol, it may be disorienting, but I would guess most of our users don't really pay attention to it (hopefully I'm wrong about that!). But the win is that if they click the login link again, they'll be back using https before they enter their password again. That would be a step towards helping our users be more secure, even if we have plenty of other bugs to close too.
I chatted with Ryan Lane briefly just now. There's no issue from ops' perspective to have logged-in users go over HTTPS. The current HTTPS infrastructure is over-provisioned and should be able to support logged-in users well. However, Ryan agrees that the usability problem of currently not auto-redirecting from HTTP to HTTPS is rather nasty and he would also really like to see that addressed before this change is implemented.
(In reply to comment #21) > (In reply to comment #20) > > In short, the issue with just setting $wgSecureLogin to true is that the user > > experience kind of sucks, as I understand it. (Feel free to correct me if I've > > misread the $wgSecureLogin-related code!) > > For any users that notice the protocol, it may be disorienting, but I would > guess most of our users don't really pay attention to it (hopefully I'm wrong > about that!). But the win is that if they click the login link again, they'll > be back using https before they enter their password again. That would be a > step towards helping our users be more secure, even if we have plenty of other > bugs to close too. The problem there though is when they hit the login link they already end up logged in. But now they are sitting on a login page, already logged in, and with no way to bypass it and get back to the page they want to edit. - If they notice they are already logged in they probably won't bother trying to log in again and will be completely confused. Not to mention that forcing someone to login when already logged in is a really ugly experience. - If they try to hit back they will return to http:// and be completely completely confused as they are no longer logged in. I think there are a few things we may want to do to improve the user experience. Firstly we should probably introduce a http cookie for users who log into https. Basically a cookie saying that a user is logged in on https. When we see this cookie on the http version of a page we should immediately redirect them to the https page. This won't be for security but rather to improve the user experience. Secondly we should probably deal with Special:Userlogin's behaviour. The act of a user ending up on a login page when logged in is really strange. There may be some value to logging in while already logged in. But I believe the primary reason for this is a holdover from login and user creation being part of the same page, needing to visit login to get to create user, and admins wanting to be able to create users while logged in. Just like with create user being the same link as login. In the long run we want create user and userlogin to be separate pages. And removal of ever having a combined login+register link, always have separate ones. Right now I think we may want to introduce a &loginlink=1 parameter like we have for &redlink=1. We'll place this on our login link. And when specified this will have the effect of automatically redirecting you to your final destination when you are already logged in. Combined these two things will have the effect of: - When you're already logged in and see a http:// link you will end up back on https:// so you are properly sitting in the place where you are logged in. - When you end up on http:// and the http cookie has disappeared and got out of sync with https clicking on the login link will land you right back on the page you were at, in the https version, already logged in, and also fix your cookie.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > >> experience, which is why I'd rather see effort focused on fixing bug 29898. > > > > But does this change require any other effort besides the change of an existing > > setting to true? > > Err, right. I think I remember what's going on here now. So there's > $wgSecureLogin, which basically changes the "log in" link to specify HTTPS. The > user clicks "log in" and he or she logs in to HTTPS and the user will stay in > HTTPS after successfully logging in. > > However, when the user clicks one of the million HTTP links (in an e-mail, on a > wiki page, on IRC, elsewhere on the Web), the user will not be automagically > redirected to HTTPS, he or she will _stay_ at HTTP and he or she won't be > logged in any longer. This is very disorienting. The user can click "log in" in > the corner of the page, but he or she will be transferred to Special:UserLogin > over HTTPS and suddenly the user will appear to be logged in again. > > In short, the issue with just setting $wgSecureLogin to true is that the user > experience kind of sucks, as I understand it. (Feel free to correct me if I've > misread the $wgSecureLogin-related code!) > > (I'm also not sure it actually prevents form submission over HTTP [if the user > navigates to the HTTP version of Special:UserLogin directly].) > > If this is an acceptable situation, it's fine to set $wgSecureLogin to true on > Wikimedia wikis. You'll need to get an okay from Wikimedia Foundation > operations (ops) first before the change can be deployed. The load spike from > logging in over HTTPS should be minimal, but the load spike from users > continuing to use HTTPS after logging in will be less negligible, I think. Ops > will also wants a heads-up so that there isn't an unexplained load spike. This is how $wgSecureLogin works, but is not how it should work. If you notice, enablind $wgSecureLogin adds a "Stay on HTTPS" checkbox to the login form. The intended functionality of wgSecureLogin is that all logins are put over HTTPS, and then the user is given back to whatever they were using before. I just tested this on my test wiki and it doesn't seem to do this, so that's probably a bug, but that's what's supposed to happen. So basically here is what needs to be fixed with $wgSecureLogin: * Actual functionality is fixed * HTTP cookie is set so user will be auto-redirected to HTTPS when logged in there. * Links on the HTTPS login page should be set to the protocol of where the user is coming from (I forget where, but there is a bug filed for this).
(In reply to comment #11) > https://gerrit.wikimedia.org/r/21322 Merged and deployed by Chris this morning.
https://gerrit.wikimedia.org/r/52344 Was reverted shortly afterward. :P
We decided to revert at the end because unchecking the box to keep the user in https didn't redirect them to http when this was running on the cluster. We may want to enable this on a smaller set of wikis, or beta, so we can debug why that is happening. In addition, I noticed that the centralauth_Session cookie is getting set with the secure flag. We may want to change that as well.
Yeah, I can't replicate the behavior on my test wiki, so maybe it's a configuration-specific bug?
I *think* the issue is that since centralauth is injecting the SUL images, then successfulLogin() calls displaySuccessfulAction() instead of executeReturnTo(). So I would bet the "Return to..." link was to an http link, but the rest of the links on the page were https since the page was still loaded over https.
(In reply to comment #24) > So basically here is what needs to be fixed with $wgSecureLogin: > * Actual functionality is fixed > * HTTP cookie is set so user will be auto-redirected to HTTPS when logged in > there. > * Links on the HTTPS login page should be set to the protocol of where the > user is coming from (I forget where, but there is a bug filed for this). Did all of this happen before this got merged/deployed? :-/ And I think a fourth point might be "get rid of the Special:UserLogin checkbox" (if that's not already included in the three points above). It's pretty bad user interface, I think. The default should just be sane.
(In reply to comment #30) > And I think a fourth point might be "get rid of the Special:UserLogin > checkbox" > (if that's not already included in the three points above). It's pretty bad > user interface, I think. The default should just be sane. Yeah, but what if the user wants to stay in HTTPS rather than go back to HTTP. Without the checkbox they no longer have an option to do so.
(In reply to comment #31) > Yeah, but what if the user wants to stay in HTTPS rather than go back to > HTTP. Without the checkbox they no longer have an option to do so. Logged-in users should be routed via HTTPS to Special:UserLogin and then stay there for however long they're logged in. A user preference (inside Special:Preferences) _may_ make sense to allow logged-in users to switch to HTTP, but the default should be HTTPS from login to logout. There's no need to have a checkbox on Special:UserLogin.
(In reply to comment #32) > Logged-in users should be routed via HTTPS to Special:UserLogin and then stay > there for however long they're logged in. A user preference (inside > Special:Preferences) _may_ make sense to allow logged-in users to switch to > HTTP, but the default should be HTTPS from login to logout. There's no need > to > have a checkbox on Special:UserLogin. But why? There's no purpose to forcing all logged in users to be over HTTPS. It's not like they're transmitting sensitive information when editing Wikipedia.
(In reply to comment #33) > (In reply to comment #32) > > Logged-in users should be routed via HTTPS to Special:UserLogin and then stay > > there for however long they're logged in. A user preference (inside > > Special:Preferences) _may_ make sense to allow logged-in users to switch to > > HTTP, but the default should be HTTPS from login to logout. There's no need > > to > > have a checkbox on Special:UserLogin. > > But why? There's no purpose to forcing all logged in users to be over HTTPS. > It's not like they're transmitting sensitive information when editing > Wikipedia. You're assuming that all Wikipedia editors live in countries and do editing tasks that they would be comfortable transmitting to the public. That's not the case. Put yourself in the shoes of someone editing from Qatar or Beijing, and ask whether it would be a good thing to automatically direct such users to HTTPS. For people not subject to that kind of extreme case... many would feel more comfortable about the security of their account and the privacy of their information if they were logged in from a secure connection. If we can add this enhancement for people, we should.
(In reply to comment #34) > You're assuming that all Wikipedia editors live in countries and do editing > tasks that they would be comfortable transmitting to the public. That's not > the > case. Put yourself in the shoes of someone editing from Qatar or Beijing, and > ask whether it would be a good thing to automatically direct such users to > HTTPS. > > For people not subject to that kind of extreme case... many would feel more > comfortable about the security of their account and the privacy of their > information if they were logged in from a secure connection. If we can add > this > enhancement for people, we should. If we're talking about extreme cases here, then what about the extreme (or maybe not-so-extreme) case of other wikis who don't have the resources to put their users over HTTPS, but they still want to make sure their users' passwords are secure? If https://gerrit.wikimedia.org/r/47089 is merged, then there will also be the technical ability to require HTTPS for all logged in users, but I think that we should keep the scope of $wgSecureLogin specific to what it was originally intended for: making logins secure.
(In reply to comment #35) > If https://gerrit.wikimedia.org/r/47089 is merged, then there will also be > the technical ability to require HTTPS for all logged in users, but I think > that we should keep the scope of $wgSecureLogin specific to what it was > originally intended for: making logins secure. I agree with keeping $wgSecureLogin within scope. For this bug, however, would you mind changing the bug summary from "Set $wgSecureLogin = true; on Wikimedia wikis" to something that captures what I think we really want here: setting $wgSecureLogin in addition to providing HTTPS by default for logged-in users? HTTPS prevents session exposure. It's obviously not critical to have, but it's a reasonable enhancement request that's been tested and provisioned for and it prevents users from accidentally shooting themselves in the foot. If other sites want to only secure login, but put users back into HTTP for everything else, that's certainly their prerogative. For Wikimedia wikis (the scope of this bug), I think we must secure logins in addition to automatically redirecting users back to HTTPS by default.
(In reply to comment #36) > I agree with keeping $wgSecureLogin within scope. For this bug, however, > would > you mind changing the bug summary from "Set $wgSecureLogin = true; on > Wikimedia > wikis" to something that captures what I think we really want here: setting > $wgSecureLogin in addition to providing HTTPS by default for logged-in users? But this requires development, which would take time. The reason I filed this bug is that (with the exception of the bug that occurs because of extensions), $wgSecureLogin is functional and only requires setting a configuration variable to true in order to enable. Personally I'd like to see all logged in users over HTTPS as well, but at the very least we could make some attempt at improving security in the meantime.
(In reply to comment #24) > So basically here is what needs to be fixed with $wgSecureLogin: > * Actual functionality is fixed > * Links on the HTTPS login page should be set to the protocol of where the > user is coming from (I forget where, but there is a bug filed for this). > * HTTP cookie is set so user will be auto-redirected to HTTPS when logged in > there. This could be done by simply enabling Strict transport security.
(In reply to comment #38) > (In reply to comment #24) > > So basically here is what needs to be fixed with $wgSecureLogin: > > * Actual functionality is fixed > > > * Links on the HTTPS login page should be set to the protocol of where the > > user is coming from (I forget where, but there is a bug filed for this). > > > * HTTP cookie is set so user will be auto-redirected to HTTPS when logged in > > there. > This could be done by simply enabling Strict transport security. I did this in Extension:SecureSessions. However, I should note that the third problem has already been fixed with the forceHTTPS cookie and the second problem can't be solved with STS.
Related URL: https://gerrit.wikimedia.org/r/68937 (Gerrit Change I17c902ae8d5e6845c938f7d6643b3d469d6e9a57)
Well, there's take two. Once the bug-fix for CentralAuth is live we can try this out again.
Change 68937 had a related patch set uploaded by Krinkle: Enabling secure login (HTTPS), second attempt https://gerrit.wikimedia.org/r/68937
Change 68937 abandoned by Ryan Lane: Enabling secure login (HTTPS), second attempt Reason: Handled in change 74268 in the correct place. https://gerrit.wikimedia.org/r/68937
Change 81563 had a related patch set uploaded by CSteipp: Secure login to true for all wikis https://gerrit.wikimedia.org/r/81563
Change 81563 merged by jenkins-bot: Secure login to true for all wikis https://gerrit.wikimedia.org/r/81563
