6 ms·
Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used? Is there a way
by sb8244 10y ago
Do you ever worry that, in the case of failure or some other event, your revocation list could be lost and allow old hacked sessions to be used?
Is there a way around this? I like the idea of a revocation list, but this seems to be a pretty big concern.
- RhodesianHunter 10y ago"old hacked sessions to be used" JWTs generally contain an expiration timestamp.
- hueving 10y agorevocation list only needs to contain tokens that haven't expired. If there is an 'event' that causes this info to be lost, then expire everything by changing the global secret.
- merb 10y agoThe same problem occurs on every other method. i.e. Bearer/Cookies. As already said the most vulnerabilities applies to all methods. But people are just too blind to see that.
- mcherm 10y agoNot particularly. There are other layers of security here - the sessions expire (so there's a limited window to exploit each one), the sessions are always transmitted via SSL (so you pretty much have to have an exploit on the customer's system to get one), and the sessions are restricted to one customer (so you only have an attack against the customer whose system you have an exploit on). If we used a different approach, then the same error (losing the data that's being synched) would result in losing all of the customer sessions.