2011-03-03

OAuth revoke bug fixed

We were notified by a user at 9:30pm that their OAuth token had not been revoked after doing a scan to find their largest emails.

We immediately shut down the site and started analyzing what had changed, as this was something we had worked on very thoroughly and something we take very seriously. To be clear, there is no security risk to user data from this, but it did mean that FindBigMail may appear on your Google Issued AuthSub Tokens page after a run when it should not. If we still had a token, it would mean that we still had access to your email account - but we delete our copy of the token immediately after we're done. It meant that our security promise to always revoke tokens immediately after use was not being kept.

It transpired that Google had changed their OAuth revoke URL from

https://www.google.com/accounts/accounts/AuthSubRevokeToken

to

https://www.google.com/accounts/AuthSubRevokeToken

and were not honoring requests to the old URL any longer. Indeed, their own "OAuth playground" still shows the incorrect URL and also does not revoke the token as it should.

We fixed the URL, tested the site, and returned it to operations at approximately 10:15pm.

Analysis

We intentionally keep very few logs, so we cannot put an exact date on when this started happening. We know that tokens were being revoked without problems as of 2/17/2011, and we know that there were problems from 3/2/2011 (we know this from some error logs, which we keep longer for analysis).

Next Steps

Ideally we would revoke all outstanding tokens, however we do not have them to revoke. We do not keep any email addresses of anyone who has used our system so we cannot simply email people who may have been affected. Our email sender has 30 day trailing logs stored at their site, so we could (painfully!) retrieve those addresses and email the users, but we feel that doing so is more of a privacy concern than the presence of the token (not to mention a significant effort for all those involved). We are going to take some technical steps to reduce the chance of a future occurance. The most signficant of these are:

  • send alert emails to the team when tokens are failed to be revoked in any situation (prevously we were getting alerts about failed revokes during problem scans, but not for succesful scans)
  • store token revoke status along with the user graph data (which is currently stored for a trailing 30 day period to allow people to see the results afterwards). Note that this does not contain any personal user information, except for a one way hash of the email address they used. (I.e. if you give us your email address we can look up a result file, but we cannot deduce your email address by looking at the results

We wanted to get this information out as quickly as possible. Please contact us if you have any questions;