Hi, I enjoyed your LPW talk today.
The question of tampering with the cookie in apps using Mojolicious::Session came up today; Sessions.md also mentioned possible tampering in the browser.
This is covered well in Day 16: The Secret Life of Sessions but key takeaways are:
- Mojolicious::Session incorporates the application secret into the cookie signature to prevent tampering.
- The user can take the contents of a cookie and the signature to try to guess - offline, so the server doesn't see anything - the contents of the secret.
- So it's really important that the secret is changed from the default - which is just the application name IIRC - to something hard to guess (random, has high entropy - the post above suggest 12 chars but I'd go with 17 or more).
- Brute-force discovery of a strong secret is impractical. (Trying all permutations is computationally infeasible.) But there's always the teeny, tiny chance that an attacker could get lucky with their guessing, so periodic rotation of the secret is a good practice.
As a side note, Mojolicious::Session uses the HMAC-SHA1 algorithm, which isn't as strong as something like HMAC-SHA256, but should still be fine for use. Use of raw SHA-1 for signatures is definitely not safe any more, but no practical attacks against HMAC-SHA1 have been made public.
Would you like a PR for sessions.md that briefly covers the above?
Hi, I enjoyed your LPW talk today.
The question of tampering with the cookie in apps using Mojolicious::Session came up today; Sessions.md also mentioned possible tampering in the browser.
This is covered well in Day 16: The Secret Life of Sessions but key takeaways are:
As a side note, Mojolicious::Session uses the HMAC-SHA1 algorithm, which isn't as strong as something like HMAC-SHA256, but should still be fine for use. Use of raw SHA-1 for signatures is definitely not safe any more, but no practical attacks against HMAC-SHA1 have been made public.
Would you like a PR for sessions.md that briefly covers the above?