nickfelt 2e969d6ed1 Change XsrfTokenManager to support new HMAC token format ... This follows up on Brian's work to transition not just to a new format with an empty scope value, but instead to replace the existing format entirely with a new one that: 1) includes a version number to support future format migrations 2) doesn't include a field for the scope at all, since scoping the tokens adds no real security benefit and just makes verification more difficult 3) replaces the raw SHA-256 hash with a SHA-256 HMAC instead, as a best practice to avoid length-extension attacks [1], even though in our particular case they would only be able to extend the timestamp and would thus be relatively innocuous The new format will be produced by calling generateToken(), and the scope-accepting version is renamed to generateLegacyToken() in addition to its existing deprecation, for maximum clarity. I changed the validateToken() logic to stop accepting a scope entirely; when validating a legacy-style token, we'll test it against the two existing legacy scope values ("admin" and "console") and accept it if it matches either one. Note that this means the xsrfScope parameter in @Action is now wholly obsolete; I'll remove it in a follow-up to avoid bringing extra files into this CL. After this CL hits production, the next one will replace all calls to generateLegacyToken() with generateToken(). Once that CL is deployed, the last step will be removing the legacy fallback in validateToken(). [1] See https://en.wikipedia.org/wiki/Length_extension_attack ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=148936805		2017-03-07 13:31:46 -05:00
..
com/google/testing/builddefs	Update copyright year on all license headers	2017-02-02 16:27:22 -05:00
google/registry	Change XsrfTokenManager to support new HMAC token format	2017-03-07 13:31:46 -05:00