
Generating Crime Safe CSRF Tokens - zdw
https://blog.hboeck.de/archives/900-Generating-CRIME-safe-CSRF-tokens.html
======
1f60c
Suggestion: edit the title to capitalize “Crime”.

At first I thought this was about _crime_ , as in police, as in burglary, as
in murder, when it’s about CRIME, as in “Compression Ratio Info-leak Made
Easy“. And the attack in question is called CRIME, not “Crime”.

------
g105b
Looking at your PHP example, I was under the impression that random_bytes()
was cryptographically secure nowadays, and already generated its pseudorandom
sequence non-deterministically?

Can you help me understand why we need to surround the output of
random_bytes() if it is already deemed cryptographically secure?

EDIT: Sorry, I have mulled your solution over now and understand that the
surrounding detail in the hash is to prevent one form's token being used in a
different form. This makes sense, and doesn't imply that random_bytes is
deterministic.

------
yuy7878
.

~~~
segfaultbuserr
CSRF itself is nothing new. What's different here is a discussion of CSRF-
generation techniques that are immune to CRIME and BEAST attacks (which are
two related, somewhat unpatchable cryptographic attacks that exploits
compression to leak information using a chosen-plaintext attack), which is not
something people often talk about.

~~~
dgoldstein0
Another solution is to set the csrf token as two cookies: one that can be read
by js via document.cookie, and another that is httponly. Js is then
responsible for including the csrf token in any requests (including forms).
This avoids crime/breach issues because cookies are part of http headers,
which are "compressed" with hpack in http2. Hpack is basically "send it once
and reference the last value many times".

Of course there are a few more details to getting this right (such as tying
csrf & auth cookies) and it doesn't hurt to also add samesite to the mix.

