1

For anti-CSRF Encrypted Token Pattern, the OWASP page describes the pre-encrypted token as being composed of three items: the user's ID, a timestamp value and a nonce.

The programmatic need for the first two is obvious but what about the third? What is the actual need for the random data component?

I get why in the case of the ordinary Synchronizer Token Pattern.

But what would be the problem for Encrypted Token Pattern with implementing a token composed of only UserId and timestamp, which is then subsequently subject to encrypt-then-mac.

Is it deemed important to make the encrypted token more cryptographically secure (by making the plaintext longer and less predictable)?

Improve this question

1 Answer 1

Reset to default
1

Not really. The nonce is there for anti-collision purposes, not cryptographic security. You could even store it as a counter in a database if you wanted; it's just that the timestamp has insufficient resolution to guarantee no collisions.

I should also point out that the patterns listed on the linked OWASP page are suggestions, and are not guarantees of security. For example, their suggested encrypted token pattern does not mention that you must use AEAD or Encrypt-then-MAC or you might as well be wasting your time. (And if you do go with Encrypt-then-MAC, you need separate encryption and MAC keys.)

Improve this answer
10
  • Would you mind expanding on that a bit? I'm not clear on what sort of collision you're referring to. The receiving server doesn't validate the nonce anyway, so if cryptographic security is not a concern, what collision risk is mitigated by adding a nonce? Suppose the token is composed only of the User Id and timestamp, and the User Id is a9b71324 and the timestamp is 20151113100733 [i.e. to-the-second granularity]. If my receiving server successfully decrypts the token and validates both the userid and the timestamp, then what is the remaining collision-related concern?
    – Henry
    Nov 13, 2015 at 15:38
  • Without the nonce, each token generated in the same single-second timespan will be identical. This is a generally undesirable property, especially since encryption is supposed to preserve confidentiality, but doesn't lead to any specific attack in this particular case. Storing the nonce would allow you to invalidate tokens, but that's not in scope for this proposal.
    – Reid Rankin
    Nov 13, 2015 at 15:55
  • 1
    But it would only be an identical token within that single-second timespan for that particular user. And even that could presumably (for all practical purposes) be avoided by making the timestamp be of to-the-millisecond granularity. Anyway, I guess that answers my question. Thanks.
    – Henry
    Nov 13, 2015 at 15:55
  • @Henry Do not underestimate what can be done in a millisecond! A single page render could easily fall within that window, especially for script execution in isolation. Besides, the more precise you get, the more you have to worry about clock skew when distributing your application over multiple servers.
    – Reid Rankin
    Nov 13, 2015 at 16:07
  • Collision of what?
    – Neil Smithline
    Nov 14, 2015 at 23:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .