Page MenuHomePhabricator

Secure login on Wikimedia wikis via SSL
Closed, ResolvedPublic


Author: wiki

It should be possible at least to login on Wikipedia, using a secure login, i.e.
https instead of http.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 6:44 PM
bzimport added a project: HTTPS.
bzimport set Reference to bz225.
bzimport added a subscriber: Unknown Object (MLST).

jeluf wrote:

https is very CPU-intensive => expensive.

the.r3m0t wrote:

How about MD5 with Javascript on the client side? That at least hides the
password, although it doesn't prevent people logging in with your account. I think.

What if you MD5'ed your password with your IP? Oh, then the server would need
your password in plaintext... damn.

askoorb wrote:

but would it?

how about sending this to the server as an MD5:


If you MD5 the whole thing the server would also be able to calculate your IP,
with any luck.

This has the problem though that the ip you machine thinks it has is not allways
the ip seen from the outside...

Another Suggestion:

How about timestamping the password with the creation time for the login page,
or some other unique(ish) stamp sent from the server? i.e. MD5ing:


So the server would check first what the timestamp sent on the latest login page
request to that client was, and then generate an MD5 with that to check with the

While certinaly NOT hacker proof. It at least means that passwords will never
be sent plain text,
and it would be difficult for the hacker to trick the server that he was
responding to the same page request as the clients, especially since only 1
timestamp would be used per logon request.

brian wrote:

(In reply to comment #1)

https is very CPU-intensive => expensive.

We now have hosting from Yahoo and may soon have hosting from
Google. There are also other organisation offering us hosting. Is it
the case that we cannot afford to use https even with this help (MD5
proposed as well, but I don't know what it is)?

For fun I half-implemented an MD5-based challenge-response login that avoids sending
the plaintext password. I'm not sure there's much benefit, though, to actually doing

The primary case where I'd be worried about sniffing of passwords is at open wireless
access points, where the network is a shared medium. In this case it's just as easy
to sniff the session cookie and hijack it -- once you're in you can use the account
with all privileges, and can probably change the password by changing the email
address and requesting a new pass.

Keying sessions to IP addresses would likely fail here too as a wifi access point
will often be NATing as well, so the malefactor likely doesn't even have to go to any
effort to spoof an IP.

The best protection would be to do a full HTTPS connection for the entire login
session, but that's difficult. Aside from the CPU power issue, HTTPS is simply
inherently unfriendly to the name-based virtual servers that we rely on.

mail wrote:

It is at least of some use, because at hacker events such as Camp Discordia,
they are running dsniff which will find passwords, but won't be so
straightforward about cookies.

I've set up an experimental SSL server for parallel encrypted access, see:

This may be ripped out and redone, depending on how rough the edges are. :)

mellon wrote:

If cookies expire in a reasonable amount of time, then using SSL to protect the
login isn't completely valueless. It's true that someone can still snoop your
cookie and use it for the lifetime of the cookie, but it's not true that
snooping your cookie gives them permanent access to the wiki. Furthermore, if
it becomes an issue (which I doubt, frankly), there are ways to notice that a
cookie is being abused and invalidate it.

Additionally, the main problem with sending passwords in the clear is not that
someone will use them to gain access to wikipedia in your name. More likely
what will happen is that they will use your stated username and password and try
to see where else you might have used the same username and password. Most
people don't keep a separate username and password for every site.

If they snoop the cookie, they can then hijack the account and take it over.
This danger would be reduced if we require the password to change the account e-mail
address in preferences.

Restored bug from flood attack.

anyfile wrote:

A client may do not know its IP as seen by the server (for instance this is
typical if the client is under a NAT).

I think that all of this issues are not pertining just to WikiMedia, but to any
MediaWiki installation. Is it possible to configure MediaWiki so that just the
login page go under encripted connection?

By the way it is not necessary to encrypt all the login page, it is enought that
just the action of the form points to an encripted connection (https). (it is
actually difficult to understood by a normal user the data will be sent encripted).

If the MD5 encription is chosen it would better if it is not only made from
password and IP address, since in a local area where IP are under NAT, the IP
address will be the same for many hosts. Adding a challange word or a timestamp
or anything else would be better.

scarreigns wrote:

security is more important than CPU cycles and the resulting expenses from these
CPU cycles. JavaScript is un-acceptable. i will not even use a website that
requires the use of JavaScript. as it is a client-side scripting engine, it has
the potential to violate my privacy, among other things i will not discuss here.

it is also less supported than SSL.  nowadays, there is no excuse for not

having optional SSL support when submitting form information, especially when it
is a username/password. if you are so concered about the $$$ involved with SSL
authentication, it does not need to be the default method when logging in.
also, if the option to use SSL authentication is selected, the entire webpage
need not be encrypted; instead, only encrypt the links of type "Form
Submission". these two ideas alone will cut back on the cost of SSL
authentication, but i'm sure you can think of others as well. wrote:

I think the time has come to implement SSL as admin accounts are getting hacked these days.

SSL does not prevent users from having crappy passwords, sadly. I'm afraid this is the probably the main reason for hacked accounts, not interception of data.

Shouldn't this issue be closed as is available?

There is no link to the secure server in the log in page of all the languages.

r75585 provides an optional feature.

(In reply to comment #16)

There is no link to the secure server in the log in page of all the languages.

This is because the secure server setup for Wikimedia projects is very unusual and therefore somewhat difficult to integrate into the interface at this moment. For wiki's that want to fix this themselves, look at adapting the following English Wikipedia messages for your wiki:

For non-wmf wikis this seems to work very well:

$wgHooks['GetLocalURL'][] = 'httpsLogin';
function httpsLogin( &$title, &$url, $query ) {
global $wgServer;
if ( $title->equals( SpecialPage::getTitleFor( 'Userlogin' ) ) ) {

		$url = preg_replace( '~^http://~', 'https://', $wgServer . $url );


return true;


gwern0 wrote:

Thought people here might find this interested with regard to the performance issue raised in the earliest 2004 comments (more than 6 years ago):

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

nykevin.norris wrote:

Is this an accurate summary of the current enhancement request (bug *is* open)?:

Make support HTTPS and (optionally) force HTTPS on Special:UserLogin.

Incidentally, I'd agree with doing that as the secure server is kind of a kludge ( and don't talk to each other; you can be logged into one and not the other).

I would like this feature to be enabled on all sister projects, not only on English Wikipedia. That is, you can optionally login from and be redirected to after you're logged in.

Huji, if you read back you will see some reasons that that solution is not great at protecting user accounts. I agree though that it is better than nothing, since we should protect our users' passwords even when we can't protect their accounts.

matt wrote:

Attempting to update the summary to describe what remains to be done.

Since this is just for the cluster, Couldn't we just update the default message in WikimediaMessages for the login page (Although that won't effect anywhere that has already customized it)?

This bug is fixed and has been for some time. I'm marking it as such.

The bug filer requested (comment 0) the ability to log in to Wikipedia via https. This is now possible at (for example)

There are tangential issues, such as whether all users should be forced to log in via https or whether interface messages need to be updated to better advertise the https option (if users aren't forced), but these are _separate_ issues. They should be filed as separate bugs, if they aren't filed already.

I'm changing the bug summary back to (the cleaned up) "Secure login on Wikimedia wikis via SSL" and marking this bug as fixed. Please file other bugs as appropriate and necessary.

psychonaut wrote:

The issue of updating the interface to better advertise the HTTPS option appears to be Bug 12807.