4 ms·
You're wrong. If this is generated every time the page loads you get a new token each time. OR you have to transmit a god awful amount of data on the same page.
by ejcx 9y ago
You're wrong. If this is generated every time the page loads you get a new token each time. OR you have to transmit a god awful amount of data on the same page.
When I work for a company that accepts GBs of data over the same TLS connection on a single page, I'll worry about breach and only generating a CSRF token every time a page loads.
- ubernostrum 9y agoFrom the sample code provided I was assuming the value would not update on every request (since, if you were changing the expiration timestamp on every request you'd have a bit more work to do than you've shown here -- and either way the sample you've provided isn't a great way to generate the token).
- ejcx 9y agoI've generated this exact token at several companies and it's worked great. An expiration of one day is not 86400 it's unix_time()+86400, to clarify. It's not stored in the users session and is completely stateless. It's great! It has every property a csrf token needs - per user - not guessable or forgeable - expires Since it is stateless it doesn't require db lookups which can be an additional benefit. If you complain that it lacks the ability to be revoked I challenge you to find a single instance of people revoking csrf tokens.
- baby 9y agoYou're wrong. If you MITM the connection you can block that response and the token will be user over and over again allowing these attacks