Last modified: 2013-06-18 16:13:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2225, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 225 - Secure login on Wikimedia wikis via SSL
Secure login on Wikimedia wikis via SSL
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Low enhancement with 22 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 20643
Blocks: 9816 ssl
  Show dependency treegraph
 
Reported: 2004-08-26 14:26 UTC by Martin Haase aka Maha
Modified: 2013-06-18 16:13 UTC (History)
22 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Martin Haase aka Maha 2004-08-26 14:26:18 UTC
It should be possible at least to login on Wikipedia, using a secure login, i.e.
https instead of http.
Comment 1 JeLuF 2004-08-27 11:17:02 UTC
https is very CPU-intensive => expensive.
Comment 2 Tomer Chachamu 2005-02-21 17:47:07 UTC
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.
Comment 3 Alex Brooks 2005-02-25 13:42:21 UTC
but would it?

how about sending this to the server as an MD5:

<Password>|<IPAddress>

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:

<Password>|<SomeExtraAccurateTimeStamp>

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
clients.

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.
Comment 4 Brian Jason Drake 2005-04-17 04:31:08 UTC
(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)?
Comment 5 Brion Vibber 2005-08-17 21:34:33 UTC
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 
this.

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.
Comment 6 Martin Haase 2005-08-25 21:58:00 UTC
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. 
Comment 7 Brion Vibber 2005-12-26 11:44:06 UTC
I've set up an experimental SSL server for parallel encrypted access, see:
http://mail.wikipedia.org/pipermail/wikitech-l/2005-December/033293.html

This may be ripped out and redone, depending on how rough the edges are. :)
Comment 8 Ted Lemon 2006-01-02 23:45:35 UTC
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.
Comment 9 Brion Vibber 2006-01-04 01:36:54 UTC
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.
Comment 10 Brion Vibber 2006-01-22 04:26:41 UTC
Restored bug from flood attack.
Comment 11 AnyFile 2006-08-15 15:32:57 UTC
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.
Comment 12 Taka Khumbartha 2006-08-29 04:08:44 UTC
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.
Comment 13 Nicholas 2008-08-01 13:19:54 UTC
I think the time has come to implement SSL as admin accounts are getting hacked these days. 
Comment 14 Chad H. 2008-08-01 13:28:38 UTC
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.
Comment 15 Siebrand Mazeland 2009-01-11 14:45:50 UTC
Shouldn't this issue be closed as http://secure.wikimedia.org is available?
Comment 16 resubew 2009-04-26 15:32:45 UTC
There is no link to the secure server in the log in page of all the languages. 
Comment 17 Antoine "hashar" Musso (WMF) 2010-10-29 16:10:24 UTC
r75585 provides an optional feature.
Comment 18 Derk-Jan Hartman 2010-10-30 13:24:19 UTC
(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:

http://en.wikipedia.org/wiki/MediaWiki:Loginend
http://en.wikipedia.org/wiki/MediaWiki:Login
Comment 19 Niklas Laxström 2010-10-30 14:36:32 UTC
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;
}
Comment 20 Gwern Branwen 2010-10-31 01:15:28 UTC
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.

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Comment 21 Kevin Norris 2010-11-21 08:04:43 UTC
Is this an accurate summary of the current enhancement request (bug *is* open)?:

Make en.wikipedia.org 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 (secure.wikimedia.org and en.wikipedia.org don't talk to each other; you can be logged into one and not the other).
Comment 22 Huji 2011-01-26 21:23:48 UTC
I would like this feature to be enabled on all sister projects, not only on English Wikipedia. That is, you can optionally login from https://xx.wikipedia.org/wiki/Specia:UserLogin and be redirected to http://xx.wikipedia.org/wiki/Page after you're logged in.
Comment 23 Rich Farmbrough 2011-02-10 15:38:17 UTC
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.
Comment 24 Matt McCutchen 2011-05-16 16:04:31 UTC
Attempting to update the summary to describe what remains to be done.
Comment 25 p858snake 2011-12-31 00:09:05 UTC
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)?
Comment 26 MZMcBride 2012-03-14 22:44:35 UTC
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) <https://en.wikipedia.org/wiki/Special:UserLogin>.

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.
Comment 27 Tristan Miller 2012-03-15 08:29:52 UTC
The issue of updating the interface to better advertise the HTTPS option appears to be Bug 12807.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links