On Mon, Oct 20, 2014 at 11:00 AM, Zack Weinberg <zackw(a)cmu.edu> wrote:
On Mon, Oct 20, 2014 at 1:38 PM, Chris Steipp
<csteipp(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l