Last modified: 2013-06-18 16:13:36 UTC
It should be possible at least to login on Wikipedia, using a secure login, i.e. https instead of http.
https is very CPU-intensive => expensive.
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.
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.
(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 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.
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: 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. :)
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.
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.
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.
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 http://secure.wikimedia.org 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: http://en.wikipedia.org/wiki/MediaWiki:Loginend http://en.wikipedia.org/wiki/MediaWiki:Login
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; }
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
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).
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.
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.
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) <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.
The issue of updating the interface to better advertise the HTTPS option appears to be Bug 12807.
