3 ms·
Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them.
by ZoFreX 10y ago
Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them.
Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier?
- wtbob 10y ago> Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. The revocation list could include entries of the form (revoke-all-tokens-before USER TIMESTAMP). You can also use stateless tokens and store them in a database until they each expire, and then just list all outstanding tokens for the user in your revocation list. Nothing says you can't use a stateless token and store it. > Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier? You have to execute your consensus protocol once for each datum synced across the cluster. It's cheaper to run that protocol once each for a short list of items than it is to run it once each for a long list of items. 'Hey everybody, please invalidate the following item, confirm!' once in a blue moon is cheaper than 'hey everybody, someone logged in, confirm!' over and over again.