https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17110 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #16 from David Cook <dcook@prosentient.com.au> --- I think time has shown that 8 hours is too short. Bug 42876 Bug 36586 - Self-checkouts will get CSRF errors if left inactive for 8 hours I think there's been other instances of CSRF tokens expiring before people can use them. Idle systems in general. I note on https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Pr... it says: "It's a common misconception to include timestamps as a value to specify the CSRF token expiration time. A CSRF Token is not an access token. They are used to verify the authenticity of requests throughout a session, using session information. A new session should generate a new token" Looking at https://metacpan.org/pod/WWW::CSRF#generate_csrf_token($id,-$secret,-\%options) We use the session ID for the ID (basically - so as to make it unique per user session), we use a server-side secret, and then the WWW::CSRF library forces us to use a timestamp which causes us the trouble. On https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Pr... it does say that per-request tokens are more secure than per-session tokens, but that it does impact usability, and that's something we've certainly encountered in Koha. If you look at Django and other frameworks, they typically do per-session tokens with per-request masking so as to prevent BREACH attacks. -- You are receiving this mail because: You are watching all bug changes.