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)?

Lighty
  • 2,368
  • 1
  • 23
  • 36
Henry
  • 11
  • 1

1 Answers1

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.)

Reid Rankin
  • 1,062
  • 5
  • 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 '15 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 '15 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 '15 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 '15 at 16:07
  • Collision of what? – Neil Smithline Nov 14 '15 at 23:09
  • Ahh. You mean a collision for when the same user logs in twice on two different browsers at the same time and receives the same CSRF token. Why is that a problem that you need to protect against? – Neil Smithline Nov 14 '15 at 23:25
  • It's not, at least in the simplest use case. But if you get fancier and do things like blacklist a token after use to prevent accidental form resubmits (or replay attacks, though you should really use TLS for that) it could become one. – Reid Rankin Nov 14 '15 at 23:30
  • The OWASP document states that this is needed for CSRF, not resubmits. Do you think that the reference is wrong? – Neil Smithline Nov 15 '15 at 01:11
  • The source is not that great, but that's not the issue. Most fundamentally, the token is not there to prevent CSRF. It's there to bind displayed HTML (or JS) to each non-idempotent action, requiring that the user visit a page before doing something. This happens to prevent CSRF, but there's no reason its usefulness must stop there. Resubmit protection is just one possible application. – Reid Rankin Nov 15 '15 at 01:43
  • What you said would make sense if only the validation section of the document said that you should validate the nonce. It just says that you should validate the user ID and time stamp. It's sounding to me that the OWASP page needs another sentence or too. You want to tackle it? – Neil Smithline Nov 15 '15 at 02:26