3 ms·

> then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. This is no more true in my technique

> then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. This is no more true in my technique than in session tokens. You have to invalidate session tokens carefully, most simply using serializable database transactions. You can do the same with the blacklist. People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong.

KirinDave 8y ago
> This is no more true in my technique than in session tokens. Which is to say that it's equally true, but you're advocating for a more ephemeral storage. > People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong. If you're leaking session tokens your entire authN/authZ system collapses I guess that's not wrong, but it's not clear that your invalidation session is as insensitive as you suggest. For example, if your token generator's RNG has flaws, you're essentially enabling that discovery via a public stoplist store. Ultimately, it's weird to imagine using something like JWT and having a request-to-authZ scheme. You have all the equipment to do short-lived renewable tokens, and then you get invalidation (to the resolution of your timing) for free and better scaling properties and a whole host of other security benefits. I personally strongly discourage people to use JWTs at all, but if you are at least take advantage of them!

3 ms·

> then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. This is no more true in my technique

by mgraczyk 8y ago

KirinDave 8y ago
> This is no more true in my technique than in session tokens. Which is to say that it's equally true, but you're advocating for a more ephemeral storage. > People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong. If you're leaking session tokens your entire authN/authZ system collapses I guess that's not wrong, but it's not clear that your invalidation session is as insensitive as you suggest. For example, if your token generator's RNG has flaws, you're essentially enabling that discovery via a public stoplist store. Ultimately, it's weird to imagine using something like JWT and having a request-to-authZ scheme. You have all the equipment to do short-lived renewable tokens, and then you get invalidation (to the resolution of your timing) for free and better scaling properties and a whole host of other security benefits. I personally strongly discourage people to use JWTs at all, but if you are at least take advantage of them!