On Mon, Oct 20, 2014 at 11:00 AM, Zack Weinberg <za...@cmu.edu> wrote: > On Mon, Oct 20, 2014 at 1:38 PM, Chris Steipp <cste...@wikimedia.org> wrote: >> * Tokens can be time limited. By default they won't be, but this puts >> the plumbing in place if it makes sense to do that on any token checks >> in the future. >> * The tokens returned in a request will change on each request. Any >> version of the token will be good for as long as the time limit is >> valid (which again, will default to infinite), but this protects >> against ssl-compression attacks (like BREACH) where plaintext in a >> request can be brute-forced by making many requests and watching the >> size of the response. >> >> To do this, the size of the token (which has been a fixed 32 bytes + >> token suffix for a very long time) will change to add up to 16 bytes >> of timestamp (although in practice, it will stay 8 bytes for the next >> several years) to the end of the token. > > I have no objection to the change itself, but I would like to make a > few related comments: > > 1) Since this is changing anyway, it would be a good time to make the > token size and structure independent of whether the user is logged on > or not. (This is probably not the only place where MediaWiki leaks > "is this user logged on?" via request or response size, but it is an > obvious place.) I think that would involve generating 'wsEditToken' > whether or not isAnon() is true, which should be fine? And then > matchEditToken() would be simpler. And anonymous editing tokens could > also be time-limited.
This is the direction I'm pushing towards. The way we handle caching at the WMF keeps this from being as simple as you have here, but yes, it's a long over due change. > 2) Since this is changing anyway, it would be a good time to stop > using MD5. SHA256 should be good for a while. Preimage attacks on md5 are still just slightly faster than brute force, so while I don't think we're in danger, I'm not opposed to strengthening this. Hopefully after this, everyone will use dynamically sized buffers, so this would be a fairly trivial change in the future. > 3) You're using the per-session 'wsEditToken' value as the HMAC secret > key. Is there anywhere that the raw 'wsEditToken' might be exposed to > the client? Such a leak would enable a malicious client to forge > editing tokens and bypass the time-limiting. There shouldn't. If any extensions do that, I would treat it as a security bug. > 4) Architecturally speaking, does it make sense to time-limit the > *token* rather than the *session*? That would be nice, but it makes it harder to do rolling validity, and this way we can also limit different types of tokens (so a checkuser token can be limited to a few minutes, while an edit token can have several hours) without having to track more secrets in a user's session. > zw > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
