-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yesterday, Werdna and Tim committed some initial code for adding shared login session state to CentralAuth. The promise of this is that not only do you have the same login state on multiple wikis, but you only have to go through the login form once -- your login will be active on the other sites as well.
There are two parts to this:
1) Central session data is maintained alongside the local sessions.
A cookie with the session key (or long-term login token) is shared across an entire domain (say, wikipedia.org), letting all wikis on that domain initialize their local sessions when you navigate to them.
2) On login, the central session cookies are set at multiple mid-level domains.
This is done by loading a special login URL at each domain as an inline image; that then sets a cookie for its domain as it's loaded. This allows us to set, for instance, a cookie for wiktionary.org when you logged in from wikipedia.org.
I've been doing some code review, local testing, and tweaking. The general theory is reasonably sound though I have some concerns and notes...
Security:
The sessions are set on other domains by passing an internal token value on a URL -- an unencrypted HTTP GET request. It's bad enough we're still passing all kinds of stuff around in unencrypted cookies, but those GET URLs go into all sorts of logs, which seems pretty creepy to me.
I'd be more comfortable with one-time-use tokens, which won't be of any use to anyone once they've seen them. Resetting them on logout only helps insofar as anyone actually logs out... I know I never do. :)
Compatibility:
Third-party cookies can be disabled by various browser options and privacy proxies. The 1x1 invisible PNG may itself be blocked by privacy or ad proxies. It may or may not be more compatible to use little iframes or something.... or that might just suck. :)
Anyway, should be considered.
Logging out:
Currently, logout only clears your global session cookies; it doesn't clear local session state. You log in once, but you may have to log out many times.
Incomplete migrations:
I haven't thoroughly tested, but my impression is that the global session state will only get set up properly if the remote wiki that happens to get hit for that domain has the global account.
If there's a non-matching local account there, it looks like it won't set the session for the whole domain.
- -- brion vibber (brion @ wikimedia.org)
On Fri, Apr 11, 2008 at 9:48 AM, Brion Vibber brion@wikimedia.org wrote:
Logging out:
Currently, logout only clears your global session cookies; it doesn't clear local session state. You log in once, but you may have to log out many times.
This was previously done by NOT setting local cookies on every single wiki that you're automatically authenticated on. Using the AutoAuthenticate hook is sufficient to stay logged-in on every wiki (although, admittedly, it's a bit nasty on the DB servers, so, depending on how much of a bottleneck that becomes, I may store the global sessions in memcached). So, the idea is, when you log out, it'll unset the global cookies, and there'll be nothing to say you're logged into that wiki, so you're logged out.
However, as of r33103, setCookies() is now called on a local user when they are authenticated by the AutoAuthenticate hook, which means that users will now have to log out on every wiki.
So yes, you're right, but only as of r33103.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Garrett wrote:
On Fri, Apr 11, 2008 at 9:48 AM, Brion Vibber brion@wikimedia.org wrote:
Logging out:
Currently, logout only clears your global session cookies; it doesn't clear local session state. You log in once, but you may have to log out many times.
This was previously done by NOT setting local cookies on every single wiki that you're automatically authenticated on.
Which means it doesn't set up a local session or update your cache timestamp, which means you see various uncached settings and your first edit fails. :)
These are bad, hence my fix.
Using the AutoAuthenticate hook is sufficient to stay logged-in on every wiki (although, admittedly, it's a bit nasty on the DB servers, so, depending on how much of a bottleneck that becomes, I may store the global sessions in memcached). So, the idea is, when you log out, it'll unset the global cookies, and there'll be nothing to say you're logged into that wiki, so you're logged out.
Plus you still had local cookies whereever you explicitly logged in.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
Security:
The sessions are set on other domains by passing an internal token value on a URL -- an unencrypted HTTP GET request. It's bad enough we're still passing all kinds of stuff around in unencrypted cookies, but those GET URLs go into all sorts of logs, which seems pretty creepy to me.
Agree. Time for secure logins ;) The excuse was that you logged in to the same domain the cookie was set to but now you lost that excuse. Make the user login to https://login.wikimedia.org/ so the user/pass is not sent in open. When you authenticate, do: *Login you into wikipedias... <img src="https://login.wikipedia.org" /> *Login you into wiktionaries... <img src="https://login.wiktionary.org" /> ..and so on
If the image loads, place a nice Ok sign. Else the placeholder should tell the user he isn't logged in on that site portion. That image is more unlikely to be blocked (browsers could start complaining that the secure site links to external domains, but there's little to do there).
Resetting them on logout only helps insofar as anyone actually logs out... I know I never do. :)
Neither do i. It's so handy being automatically logged for weeks...
Also, when is AutoAuthenticate called? I don't see it being clear on hooks.txt nor the code (and it's late for starting following the calling procedures). Is it called on any page view or only when you're going to edit/login page? I think the latter would be preferred for SUL. And auto-creation could require a "Do you want to create your local account?" step if your action is not explicit to enter.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides wrote:
Also, when is AutoAuthenticate called? I don't see it being clear on hooks.txt nor the code (and it's late for starting following the calling procedures).
When unstubbing the $wgUser object.
Is it called on any page view or only when you're going to edit/login page?
Any hit that requires a user object; which is to say, pretty much anything. :)
I think the latter would be preferred for SUL. And auto-creation could require a "Do you want to create your local account?" step if your action is not explicit to enter.
The current code as written won't create a local account that doesn't yet exist -- you'd have to log in at least once per site.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
Platonides wrote:
Also, when is AutoAuthenticate called? I don't see it being clear on hooks.txt nor the code (and it's late for starting following the calling procedures).
When unstubbing the $wgUser object.
I arrived to the UserStub, the problem was in determining which caused the User to be unstubbed. "pretty much anything" explains that.
On Fri, Apr 11, 2008 at 9:48 AM, Brion Vibber brion@wikimedia.org wrote:
Security:
The sessions are set on other domains by passing an internal token value on a URL -- an unencrypted HTTP GET request. It's bad enough we're still passing all kinds of stuff around in unencrypted cookies, but those GET URLs go into all sorts of logs, which seems pretty creepy to me.
I'd be more comfortable with one-time-use tokens, which won't be of any use to anyone once they've seen them. Resetting them on logout only helps insofar as anyone actually logs out... I know I never do. :)
Brion already knows this, but for completeness, I addressed this a few days ago.
Incomplete migrations:
I haven't thoroughly tested, but my impression is that the global session state will only get set up properly if the remote wiki that happens to get hit for that domain has the global account.
If there's a non-matching local account there, it looks like it won't set the session for the whole domain.
This is inaccurate. Authentication of the token stored in memcached and addressed by a one-time token given in the GET parameters is done against the central DB. There was a silly and probably broken line in AutoLogin which loaded a corresponding local account for the sake of storing the 'rememberpassword' option, but I refactored that out in r33176.
On Sat, Apr 12, 2008 at 4:36 AM, Brion Vibber brion@wikimedia.org wrote:
This was previously done by NOT setting local cookies on every single wiki that you're automatically authenticated on.
Which means it doesn't set up a local session or update your cache timestamp, which means you see various uncached settings and your first edit fails. :)
These are bad, hence my fix.
I asked Tim, and he told me there wasn't any reason to be setting local cookies in doing this, so I removed that line from wfCentralAuthSessionInit.
Note that, in order to address issues of caching after you've logged out, I've added a LoggedOut cookie, and added this to the list of vary-options cookies.I'm not sure if I'm supposed to be setting User::mTouched if that cookie's present as well, and, if so, I'm happy to do that.
Plus you still had local cookies whereever you explicitly logged in.
I'm getting there.
I hope I've gotten a little bit closer to addressing all your concerns :-). For full details of today's work, see this commit message:
http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=33176
Thanks for having a close look at this.
Andrew Garrett wrote:
On Sat, Apr 12, 2008 at 4:36 AM, Brion Vibber brion@wikimedia.org wrote:
This was previously done by NOT setting local cookies on every single wiki that you're automatically authenticated on.
Which means it doesn't set up a local session or update your cache timestamp, which means you see various uncached settings and your first edit fails. :)
These are bad, hence my fix.
I asked Tim, and he told me there wasn't any reason to be setting local cookies in doing this, so I removed that line from wfCentralAuthSessionInit.
Note that the local session needs to initialised, for the benefit of edit tokens and the like. But the session does not need to contain authentication data, and the local authentication cookies do not need to be set. If there are any local authentication cookies (session or persistent), we would need to have a way of deleting them on logout. It's bad enough deleting cookies for 8 second-level domains.
This is what Andrew has implemented, a local session which does not log you in.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, quick update, I've done a basic assessment of the additional security impact of global session cookies and some mitigration strategies:
http://www.mediawiki.org/wiki/Global_session_threat_assessment
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brion Vibber wrote:
Ok, quick update, I've done a basic assessment of the additional security impact of global session cookies and some mitigration strategies:
http://www.mediawiki.org/wiki/Global_session_threat_assessment
Status update...
* Werdna's added support for HttpOnly cookies under PHP 5.2. Currently we can't deploy this until we finish upgrading some of our machines.
* I've enabled global sessions on secure.wikimedia.org, where there's a single domain and few other services to increase the attack surface. It _seems_ to mostly work so far. ;)
Logging out doesn't quite clear all sessions correctly yet, but so far so good. :)
- -- brion
wikitech-l@lists.wikimedia.org