Page MenuHomePhabricator

Auth tokens should expire
Open, LowPublic

Description

Login token cookies (set by MediaWiki core and by CentralAuth) have a 30-day expiration date, but we don't do anything to enforce that on the server side. If the goal of the relatively short expiration time is to limit the effect of stealing login cookies, we shouldn't rely on the client to be honest and honor the expiry date.

We could use something similar to Token::toStringAtTimestamp to issue tokens which include an expiration timestamp.

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr changed the visibility from "Public (No Login Required)" to "Custom Policy".
Tgr changed the edit policy from "All Users" to "Custom Policy".
Tgr changed Security from None to Software security bug.
Tgr added a subscriber: Tgr.

I think the reason is more that the old privacy policy specified a 30-day
maximum on cookies.

I think the reason is more that the old privacy policy specified a 30-day
maximum on cookies.

I think that's right.

If we don't much care, should we decline the tas and remove custom policy, given that we use 1 year now on Wikimedia and half a year on default MW installs? @dpatrick any thoughts?

@dpatrick: Any feedback on the question in the last comment?

If we don't much care, should we decline the tas and remove custom policy, given that we use 1 year now on Wikimedia and half a year on default MW installs?

Any thoughts / answer from a Security team member, please?

sbassett added a subscriber: sbassett.

Seeking input from Security-Team hence adding tag

Reviewed at the Security-Team clinic today.

If we don't much care, should we decline the task and remove custom policy, given that we use 1 year now on Wikimedia and half a year on default MW installs?

I'll do this now. This would be a good code hardening measure in the Security-Team's collective opinion, but without a confirmed vulnerability which becomes an increased threat within an additional 11-month period as opposed to a 30-day period, this doesn't seem quite as urgent. If such vulnerabilities do exist, we'd be happy to reevaluate this.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Feb 22 2021, 4:15 PM
sbassett changed the edit policy from "Custom Policy" to "All Users".
Aklapper lowered the priority of this task from Medium to Low.Feb 22 2021, 7:12 PM