Fix comments about csrf_state

[ikehz]

Clarify that the state parameter should be compared to the csrf_token.secret().

Fixes #208.

[ramosbugs]

Hey, thanks for fixing the variable name! I would prefer not to add .secret() as it suggests users should directly compare the secret as a string using ==, which would create a timing side-channel vulnerability.

To avoid introducing the vulnerability, the comparison must be done in constant time, either using a constant-time crate like constant_time_eq (which could break if a future compiler version decides to be overly smart about its optimizations), or by first computing a cryptographically-secure hash (e.g., SHA-256) of both values and then comparing the hashes using == (see #232).

The timing-resistant-secret-traits feature flag adds a safe (but comparatively expensive) PartialEq implementation to the secret types. Timing side-channels are why PartialEq is not auto-derived for this crate's secret types, and the lack of PartialEq is intended to prompt users to think more carefully about these comparisons.

I would suggest either only fixing the variable name, or adding a separate section about securely comparing secrets such as the CSRF state, and then referencing it in each example.

[ikehz]

Thanks so much for the thorough feedback! Fixed instructions to compare just against csrf_token. Sent #246 for the additional docs.

[ramosbugs]

Thanks!