When a user on facebook grants an app access to their account, an API key is iss

Question

When a user on facebook grants an app access to their account, an API key is issued to the app. This key is app and user-specific. This process is described in Facebook's developer documentation.

Until recently, API keys could be parsed- they contained the app's numeric ID, the user's ID, and other information (timestamps, validity, etc) encoded and used by Facebook to track the app and grant/revoke permissions.

As described in Facebook's documentation, https://developers.facebook.com/docs/oauth2-https-migration/, the access tokens given to apps are now encrypted. What does Facebook accomplish by encrypting the access token? Other than the fact that you can no longer tell by looking at it what user and app it belongs to, nothing is changed from what I can tell. If the token is stolen, it can still be used, encrypted or not, to access the user's account.

Explanation / Answer

Disclaimer: I am writing this based only on what you write and my own guesswork.

Last I saw something about "encrypted tokens", it was about server load. When an app uses such a token, the token must be verified against what can be described as a big database of all existing valid tokens. Possibly, some people could have begun to try "random tokens" just in case it works (cost of trying a random token is about 0 for an amateur who will just try out a dozen or so, but the perceived potential gain is high). Risks of hitting a valid token are negligible (if the token includes enough secret random bits) but each such token must still be validated against the Big Database, and given the size of Facebook's user base, one can surmise that this implies a tremendous extra load on that database.

A way to reduce such load is to use a MAC: a keyed integrity check. Facebook's servers would first verify the MAC (with the secret key used to generated the MAC in the first place) and only tokens with a proper MAC would be forwarded to the database for the more expensive verification.

There are several methods to make a keyed integrity check; one of them is to add some "redundancy" in the token structure (e.g. a field consisting in a sequence of zeros) and then encrypting the whole with a pseudo-random permutation (a block cipher, using the whole token as a single "block"). To verify, the token is decrypted and the presence of the redundancy is verified. There is ample room for doing it wrong (e.g. if the token is longer than a cipher block, and an inadequate chaining mode is used) but it is still a possibility.

Therefore, without any other information, I find it possible that the "encrypted token" could be a keyed integrity check in disguise, meant to reduce server load.

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.