4 ms·

On the nonce-tracking front, what about a monotonic counter? The client can generate the next nonce by incrementing the previous nonce value. The server only

On the nonce-tracking front, what about a monotonic counter? The client can generate the next nonce by incrementing the previous nonce value. The server only needs to remember the highest nonce it's ever seen, for a particular session, and reject any new nonces less than or equal to it. O(1) in time and space, and no need for anything clever like bloom filters. Edit: One issue I can see with this approach would be, what if requests arrive (or are processed) out-of-order? You'd perhaps want to track a small window of nonces to account for this.

red_admiral 3y ago
Would this still work if the client opens more than one tab?
- Retr0id 3y ago
  As long as you have some mechanism for synchronizing state between tabs, it should be fine. iiuc, the localstorage API is synchronised, for example.
  - katsura 3y ago
    Except if you have two almost simultaneous requests where the request made last reaches the server first.
notpushkin 3y ago
> You'd perhaps want to track a small window of nonces to account for this. Just send a signed UTC timestamp instead of a nonce. Make it valid for like 5–15 seconds to ensure it doesn't break if clocks are out of sync slightly – it will still be better than cookies that live practically forever.