トークンの128ビットのエントロピーは事実上の標準であると考えます。 [〜＃〜] owasp [〜＃〜] と [〜＃〜] cwe [〜＃〜] はどちらも最低限これを推奨します。 Base64の20文字（120ビットに対応）も、URLの何かに便利です。また、多くの場合、これらのトークンのシードが不十分だと問題が発生します。参考までに、 http://samy.pl/bh10/ の（味のない装飾が施されているが、非常に有益な）スライドを参照してください。
エントロピーソースを適切に選択してください。
これは古い質問ですが、この質問を検討する機会があり、少なくともいくつかのおよびCSRFライブラリがデフォルトで使用するものを調査することにしました。私の結果は次のとおりです。
Django : 32 random characters from the set [a-zA-Z0-9] : 190.53 bits of entropy Ruby on Rails : 32 bytes of entropy (encoded as base64) : 256 bits of entropy Spring Security : UUID4 (actually, this seems to use a PRNG, not an RNG, if I'm not mistaken) : 122 bits of entropy OSASP PHP CSRF Guard (https://www.owasp.org/index.php/PHP_CSRF_Guard) : 128 characters from the set [a-z0-9] : 661.75 bits of entropy OWASP J2EE CSRF Guard : 32 characters in the set [A-Z0-9] : 165.44 bits of entropy Oracle ATG version 10.1.1 : a standard Java "long" encoded using ascii base 10: 64 bits of entropy
私のサンプルは、よく知っているソースコードやフレームワークにアクセスできるフレームワークに大きく偏っています。
私は特に、64ビット以下のエントロピーを使用して、ATGが標準のJava "long"を使用して失敗した理由を正当化するフレームワークを見つけようとしました。そのため、私の結論は64です。ビットはおそらく短すぎます。
とはいえ、攻撃者が1秒あたり100,000件のリクエストを実行できるとすると、64ビットのCSRFトークンを総当たりするのに平均で約293万年かかるはずです。 （そして、セッションIDとは異なり、トークンスペース全体に複数のトークンがあってはなりません。）したがって、おそらく64ビットで十分です。
2 ^ 63 / (100,000 * 60 * 60 * 24 * 365) = 2.93 * 10 ^ 6
CSRFでは、攻撃者は多くの推測を行うことができます。従業員が攻撃者のサイトにアクセスして、クリスマス休暇に行くとどうなりますか？攻撃者は何百万ものクロスサイトリクエストを行う可能性があります。セッションIDについても同様の懸念があります。どちらかの値が取得されると、セッションが危険にさらされます。 CSRFトークンとセッションIDの両方に同じ強度基準を適用する必要があります。
どちらの場合も値の期限が切れていることを確認してください。攻撃者は1週間で2 ^ 128のリクエストを行うことはできませんが、最終的には可能になります。乱数ジェネレーターが弱い場合、2番目の128番目の暗号ナンスがあると思うかもしれませんが、それよりはるかに少ない場合があります。