4 ms·

The reality is that hardly anything needs to be instant. You're powerless in the time period that you're setting. You don't need to have Reddit-scale traffic t

The reality is that hardly anything needs to be instant. You're powerless in the time period that you're setting. You don't need to have Reddit-scale traffic to have to consider this, but when you deal with a lot of backend systems it can reduce complexity a lot.

tptacek 8y ago
Isn't this like the one component of an application design where you really do need it to be instant? People get confused because invalidation doesn't happen often. But you also don't use a fire extinguisher often, and you get those checked all the time to... wait, bad example.
- vegardx 8y ago
  I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough. That said, I don't think a lot of people really take this into consideration when they use a stateless JWTs, or the computation required to issue really short lived tokens. Aaaand now I have to check my fire extinguisher.
  - zerkten 8y ago
    > I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough. I think the right answer is that you need to develop some type of threat models, review them periodically, and then decide what's right. Just because you can't think of a problem with the approach now doesn't mean it won't happen later, or be a component of a larger attack. The "given time frame" above may be more than enough for certain attacks you can identify in initial threat modeling. From the long-term operational perspective, it may also be preferable for the application owner to have immediate invalidation. This might be inconvenient to the development team just trying to get their work done now, but is it a good idea to ignore this requirement? For various reasons, dev teams tend to push on only for there to be problems later.

tptacek 8y ago

Isn't this like the one component of an application design where you really do need it to be instant? People get confused because invalidation doesn't happen often. But you also don't use a fire extinguisher often, and you get those checked all the time to... wait, bad example.

vegardx 8y ago
I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough. That said, I don't think a lot of people really take this into consideration when they use a stateless JWTs, or the computation required to issue really short lived tokens. Aaaand now I have to check my fire extinguisher.
- zerkten 8y ago
  > I guess that depends on the application. So long as you can guarantee that it happens within a given time frame that might very well be good enough. I think the right answer is that you need to develop some type of threat models, review them periodically, and then decide what's right. Just because you can't think of a problem with the approach now doesn't mean it won't happen later, or be a component of a larger attack. The "given time frame" above may be more than enough for certain attacks you can identify in initial threat modeling. From the long-term operational perspective, it may also be preferable for the application owner to have immediate invalidation. This might be inconvenient to the development team just trying to get their work done now, but is it a good idea to ignore this requirement? For various reasons, dev teams tend to push on only for there to be problems later.