Talk:Requests for comment/Login security

Archive

There is a discussion about this RfC on wikitech-l starting on August 23, 2013 (gmane).

Policy-based rules

The code to implement the current plan of record was somewhat hacky, and I think the entire process, and what is encrypted or not could be much more clearly understood (and implemented) as a set of policies around the 4 areas (anonymous browsing, user login, logged-in browsing, sensitive activities) where we can use HTTPS.

For each area, we could define a site policy which specifies of https is required, recommended (defaults to https, but user pref can override), or unspecified. At the 2 where we have an identified user, we can have a user preference to allow the user to specify their choice for when the site policy only recommends or doesn't specify. For the 2 areas where we deal with anonymous users, we could allow a way for the anonymous visitor to specify a preference with a cookie, possibly. —The preceding unsigned comment was added by 50.136.243.106 (talk • contribs) 03:04‎, Aug 25, 2013 (UTC)

I find it interesting that so many folks are talking about cookies at the same time as talking about login security. I don't think I'm unique in wiping cookies when shutting down a browser, and people who have multiple "computers" (including smartphones, tablets, laptops and desktops) won't gain any benefit if preferences are cookie-based, since they'll have to be set on all that different equipment. Risker (talk) 02:41, 27 August 2013 (UTC)

The problem is that per-user preferences stored in MediaWiki's database can't apply before you're logged in, or to the current login form itself, since the system can't know who you are until after you log in. So for non-logged-in users things either have to apply to everyone or there has to be some mechanism to indicate these preferences without being logged in, for which the usual solution is cookies (in fact, being logged in on MediaWiki also uses cookies). Anomie (talk) 15:02, 27 August 2013 (UTC)

Some thoughts

Here are some of my thoughts when I read the RfC. I’m sorry of the length of the text, I had difficulties to make it short.

Groups of people affected

• Minor point: there are also non-human editors (bots/programs); I guess these could more easily fall into the #3 or #4 category (https not taken into account and/or disabled for performance reasons)
• The breakdown should also take into account a same human nowadays uses many devices (e.g. smartphone, tablet, computer) from various places (e.g. free wifi, home, work), therefore s/he potentially navigate between the categories #1, #3 and #4. Therefore the solutions should be decided if they apply on the session/browser level (cookie) or on the entire user level (hard preference).
• A variation of the previous point is the regular travellers from/to blocked countries (mainly China I guess); they navigate between #2 and the other categories. As an example a person with a smartphone should be allowed to disable HSTS (set max-age=0) before arriving in China, else s/he will not be able to use Wikipedia in China.

Longer Term Question #1

• Minor point: (mentionned by Tyler on wikitech-l) the user group for anonymous users for before login is the same (because we don’t know who will be the user), so it’s not a parameter we can count on in order to decide HTTPS or HTTP for the login; therefore if there is some HTTP somewhere and if the user (even with steward rights) logs in this HTTP form, s/he will send its credentials in cleartext, even if MediaWiki refuses later to let him/her log in.
• More generally, if there is any opt-out HTTPS (such as GeoIP or url parameter or cookie) there could be some insecure situations where a user log in on HTTP, possibly without knowing it. Perhaps a solution would be to make really visible when the user log in on HTTPS with a big safe on the page, and a big unsafe (:-) when s/he log in on HTTP. I think an active attacker can simulate on a HTTP page the HTTPS safe, but it will be more difficult to do than the current situation and we can render it quite difficult (e.g. use CSS data images instead of external images).
• Main point: About the question "Should MW allow http?" I feel it is partly related to the question "How good are the reasons the user want http?": is it because the user is truly https-unable because of its corporate/country firewall? is it because the https has some issues the user doesn’t want to take time to solve them? is it because performance is not as good as in http? and these questions have to be balanced with "the user don’t know well computer security" and/or "the user has high responsabilities with his/her account (checkuser/oversight/steward)" and "we (community) have concerns about letting the NSA spy our visitors/editors". Therefore from the MediaWiki point of view (Wikimedia is not the sole user of MediaWiki) I would respond MediaWiki should let the server administrators decide (with the users) what is the best for a particular website, and therefore MediaWiki itself should have a variety of fine configuration parameters: mandatory HTTPS for everyone (server option), option GeoIP or not (server option), option opt-out by url parameter (server option, possibly user preference), option cookie or not (forceHTTP, forceHTTPS -- server option + possibly user preference), and allow some hooks for the extensions (as it was done in the last days), but absolutely let the choice to the server administrators.
• UI: Perhaps, in order to simplify the options from the user point of view, the user (and the anonymous users being a particular user type -- '*' in the authorisation framework) can be given the choice of the HTTPS strength s/he want (with the specific configuration of each level defined by the server administrator, and the change of level can require some authentication strength (see question #3)):
  • Hard HTTPS: require HTTPS no matter where I live and the devices I use, even if I may be unable to visit in case of HTTPS problem; example of config: forceHTTPS cookie, force redirect to HTTPS, HSTS with long max-age;
  • Soft HTTPS: try to stay on HTTPS if the device permits; example of config: force HTTPS cookie (and if not present stay on HTTP and let the user authenticate on HTTP), HSTS with short max-age (e.g. 2 days);
  • Equal HTTP/HTTPS: I want to be logged on HTTP and HTTPS and please not force me to use one or the other; example of config: secure and unsecure cookies, no forceHTTPS cookie, no redirect, HSTS with max-age=0 (to remove this security before a travel);
  • Refuse HTTPS: I want to stay on HTTP; big warnings: security, "you can be required to use HTTPS for some actions", etc.; example of config: unsecure cookies, forceHTTP cookie, force redirect to HTTP
• I wonder if it is worth to give an option to create, in the "soft HTTPS" and "equal HTTP/S" cases, two session cookies: one secure and one unsecure to be sure of the security of the HTTPS connection.

Longer Term Question #2

Imho the response can be similar to the previous question: let the server administrator decide with the users for a particular website; perhaps some option to change the default settings depending of the specific device.

Longer Term Question #3

Apart for the login action, the actions could require some authentication strength (password, strong password, HTTPS connection, client SSL certificate, two-level authentication, etc.) in addition of the current authorisation framework. In the softwares I know, the authorisation rules of Sympa (mailing-list server) can require some authentication strength/methods (smtp, md5, smime).

PS: it’s not directly related to this RfC but to the Wikimedia projects in the medium term, I find it could be created a gadget setting (as opt-in) a forceHTTPS cookie for the anonymous users (it will increase the HTTPS load), and possibly inform them when they click on the button/link about HTTPS-Everywhere and the improved security of the accounts.

~ Seb35 16:56, 27 August 2013 (UTC)

About the PS, I wrote a script/gadget to add a link in the colophon of the page setting/removing a forceHTTPS cookie, for anonymous and/or logged-in users. ~ Seb35 10:52, 28 August 2013 (UTC)

3rd party users

While I am totally in favour of all HTTPS on public sites, we have to consider 3rd parties using MediaWiki in intranets. In this case, HTTPS is not always the preferred option, since 3rd parties here commonly have to use self-signed certificates for budget reasons, which gives them "Scary Browser Warnings" (TM). How about an opt-out configuration like $wgNoHTTPSAndYesIKnowWhatImDoing (or something that sounds more serious :)? --Mglaser (talk) 20:41, 14 October 2013 (UTC)

obsolete?

Hi; is this RfC still active and needed, or is it obsolete? Sharihareswara (WMF) (talk) 19:28, 21 July 2014 (UTC)

I guess it’s obsolete. HTTPS was deployed for all logins except for IPs from Iran and China, and most of the discussed topics are now historic. Probably the longer term questions should be refactored in a new actualised RfC if needed. ~ Seb35 [^_^] 13:01, 20 September 2014 (UTC)