I propose to raise the default ($wgCookieExpiration) at least to 90 days from current 30.
This setting was supposed to combat leakage of logged in sessions by making them expire before before an attacker grabs them. However, cookie expiry does little to stop bad guys and annoys good ones:
* Once you've left a public PC without clicking on "log out", your session is already compromised, even making cookies session-only won't help. * If nobody looks specifically for your session, they can stumble upon it accidentally, while browsing the same site as you did. Lowish expiry time can indeed help lessen this possibility, however with Wikipedia's popularity there's pretty solid chance that someone will visit it from a public teminal within hours, not days. Less popular sites are, on the other hand, protected by smaller possibilities of someone looking for them. * MediaWiki provides no way to adjust preferences without having an account, so advice "register and set this or that in 'my preferences'" is pretty popular these days. However, the need to log in every month which is mildly annoying for wiki regulars, may have a drastic effect on casual visitors. "You told me to register and when I did, I had to relogin after a couple of visits!!1"
Taking this all into account, I see no reason to keep the current default.
Max Semenik wrote:
I propose to raise the default ($wgCookieExpiration) at least to 90 days from current 30.
What's the reason for having the cookie expire at all (or expire in any reasonable timeframe)? I'm not sure I see what security benefits any expiry provides (much less a 30-day one) given the rampant use of password stores in browsers.
Another option would be to add a user preference for cookie expiry, but suggesting the addition of new user preferences usually activates the Aryeh rage machine. :-)
MZMcBride
MZMcBride <z <at> mzmcbride.com> writes:
What's the reason for having the cookie expire at all (or expire in any reasonable timeframe)? I'm not sure I see what security benefits any expiry provides (much less a 30-day one) given the rampant use of password stores in browsers.
Setting the cookie expiry to practically infinite would also solve bug 24892 [1].
On Sun, Aug 22, 2010 at 4:09 PM, MZMcBride z@mzmcbride.com wrote:
What's the reason for having the cookie expire at all (or expire in any reasonable timeframe)? I'm not sure I see what security benefits any expiry provides (much less a 30-day one) given the rampant use of password stores in browsers.
The major purpose that I know of is so that users who don't have their browser save their passwords are actually forced to enter their password once in a while so they don't forget it. I don't know if there's any other reason for it.
Another option would be to add a user preference for cookie expiry, but suggesting the addition of new user preferences usually activates the Aryeh rage machine. :-)
GRRAAARRR!!!!!!!!! >:(((
On Sun, Aug 22, 2010 at 4:38 PM, Platonides Platonides@gmail.com wrote:
Instead of randomly increasing the cookies lifetime, I think that we should be renewing the cookies if the session has more than eg. 24 hours. That way, you would never need to login again if you browsed the wiki at least once in the last month.
Personally, I don't find annoying having to log in once a month. It's the CentralAuth third party cookies (+ firefox behavior) what makes them expire.
It's not annoying if you're a frequent user, particularly not if you have your browser save passwords. But it's really annoying on sites you only visit once in a while and aren't committed to at all. If you find yourself logged out when you visit, odds are good you won't bother logging in, particularly not if you don't have the password saved (which is more likely if you very rarely visit the site).
Max Semenik wrote:
I propose to raise the default ($wgCookieExpiration) at least to 90 days from current 30.
This setting was supposed to combat leakage of logged in sessions by making them expire before before an attacker grabs them. However, cookie expiry does little to stop bad guys and annoys good ones:
- Once you've left a public PC without clicking on "log out", your
session is already compromised, even making cookies session-only won't help.
- If nobody looks specifically for your session, they can stumble upon
it accidentally, while browsing the same site as you did. Lowish expiry time can indeed help lessen this possibility, however with Wikipedia's popularity there's pretty solid chance that someone will visit it from a public teminal within hours, not days. Less popular sites are, on the other hand, protected by smaller possibilities of someone looking for them.
- MediaWiki provides no way to adjust preferences without having an
account, so advice "register and set this or that in 'my preferences'" is pretty popular these days. However, the need to log in every month which is mildly annoying for wiki regulars, may have a drastic effect on casual visitors. "You told me to register and when I did, I had to relogin after a couple of visits!!1"
That's better than the "I don't remember what my password is since I never needed to input it, I was always logged in." reports.
Instead of randomly increasing the cookies lifetime, I think that we should be renewing the cookies if the session has more than eg. 24 hours. That way, you would never need to login again if you browsed the wiki at least once in the last month.
Personally, I don't find annoying having to log in once a month. It's the CentralAuth third party cookies (+ firefox behavior) what makes them expire.
On 23.08.2010, 0:38 Platonides wrote:
That's better than the "I don't remember what my password is since I never needed to input it, I was always logged in." reports.
This point is debatable:) At least we inform people that they should provide valid emails if they want to reset their passwords.
Instead of randomly increasing the cookies lifetime, I think that we should be renewing the cookies if the session has more than eg. 24 hours. That way, you would never need to login again if you browsed the wiki at least once in the last month.
That would require some effort, and will add another cookie that stores expiry time. A simple increase in time will be a fine solution until a complex scheme is implemented (do we want it at all? more cookies=more bandwidth). Additionally, there's still no good reason to keep expiry time short anyway.
Personally, I don't find annoying having to log in once a month. It's the CentralAuth third party cookies (+ firefox behavior) what makes them expire.
I don't use FF, can you elaborate?
On Mon, Aug 23, 2010 at 2:06 PM, Max Semenik maxsem.wiki@gmail.com wrote:
This point is debatable:) At least we inform people that they should provide valid emails if they want to reset their passwords.
Just today Gmail put a message at the top of the screen complaining that I didn't have a phone number or backup e-mail set to recover my password, and nagged me to do so. I guess it only does that to people who have been using it for X months, have more than Y MB of mail stored, something like that. Maybe we should nag established users without confirmed e-mail to set one, once in a while. (Doesn't help if they can't access the address anymore, though . . .)
That would require some effort, and will add another cookie that stores expiry time. A simple increase in time will be a fine solution until a complex scheme is implemented (do we want it at all? more cookies=more bandwidth). Additionally, there's still no good reason to keep expiry time short anyway.
I don't see any reason to increase it to 90 days -- if we increase it at all, may as well make it not expire.
Max Semenik wrote:
Instead of randomly increasing the cookies lifetime, I think that we should be renewing the cookies if the session has more than eg. 24 hours. That way, you would never need to login again if you browsed the wiki at least once in the last month.
That would require some effort, and will add another cookie that stores expiry time. A simple increase in time will be a fine solution until a complex scheme is implemented (do we want it at all? more cookies=more bandwidth). Additionally, there's still no good reason to keep expiry time short anyway.
Nope. It's just another field in the session storing when was it last set. If it wasn't today, update it and overwrite the cookie with the new expiry. For frequent users, renewing at something like $wgCookieExpiration would work fine, but would fail for the guy which uses the wiki twice a month, and the central day is precisely the day before it starts being renewed.
Personally, I don't find annoying having to log in once a month. It's the CentralAuth third party cookies (+ firefox behavior) what makes them expire.
I don't use FF, can you elaborate?
I have it configured to remove cookies at end of session (except for a few domains, like wikipedia.org). If I log in via wikipedia.org, it is persistent and all is good. If I log in via a non-whitelisted domain, the third party wikipedia.org cookie gets downgraded to a session cookie.
Would it be possible for a user to create a small javascript to replace the default cookie by another one which doesn't expires?
Helder
On Sun, Aug 22, 2010 at 16:20, Max Semenik maxsem.wiki@gmail.com wrote:
I propose to raise the default ($wgCookieExpiration) at least to 90 days from current 30.
This setting was supposed to combat leakage of logged in sessions by making them expire before before an attacker grabs them. However, cookie expiry does little to stop bad guys and annoys good ones:
- Once you've left a public PC without clicking on "log out", your
session is already compromised, even making cookies session-only won't help.
- If nobody looks specifically for your session, they can stumble upon
it accidentally, while browsing the same site as you did. Lowish expiry time can indeed help lessen this possibility, however with Wikipedia's popularity there's pretty solid chance that someone will visit it from a public teminal within hours, not days. Less popular sites are, on the other hand, protected by smaller possibilities of someone looking for them.
- MediaWiki provides no way to adjust preferences without having an
account, so advice "register and set this or that in 'my preferences'" is pretty popular these days. However, the need to log in every month which is mildly annoying for wiki regulars, may have a drastic effect on casual visitors. "You told me to register and when I did, I had to relogin after a couple of visits!!1"
Taking this all into account, I see no reason to keep the current default.
-- Max Semenik ([[User:MaxSem]])
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
At 2010-08-24 14:51, Helder Geovane wrote:
Would it be possible for a user to create a small javascript to replace the default cookie by another one which doesn't expires?
Probably not unless some browser don't respect HttpOnly flag of cookies.
But you could make an extension for a browser like Firefox and probably even GreaseMonkey script to do that.
Also some browsers (e.g. Opera) allow you to change cookie settings with their built in cookie managers. So you might set up cookie expiry for say... 2100-01-01 or something like that.
Regards, Nux.
wikitech-l@lists.wikimedia.org