5 ms·

> Since the blacklist is just a collection of random token IDs, it isn't sensitive. You can store it anywhere, including in memory in your web servers or in a d

> Since the blacklist is just a collection of random token IDs, it isn't sensitive. You can store it anywhere, including in memory in your web servers or in a distributed cache. You can wait during blacklist/token invalidation events until the newly blacklisted token has been propagated. This is very dangerous advice. If you're advocating for the addition of a fast blacklist storage, you really haven't changed your previous pattern complaint, but the dangeous bit of your advice is implying that it's simple to store "anywhere" such as "in memory in your web servers." That is a bad idea. If your authentication model is depending on an explicit stop-list to invalidate tokens, then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. A loss of integrity in this data store in unacceptable. Even some eventual consistency can be dangerous (but is generally accepted as a risk if the time envelope is acceptable). It's much better (from a security standpoint) to have very short lived tokens and constantly revalidate. The revalidation cycles CAN be full database cycles since they occur at a reduced rate, and you can then have more sophisticated policies there without too much trouble. > All of this is around 90 lines of python in my Django site. I don't doubt it, but trying to scale your advice to a product or to an environment with actual concurrency opens up a lot of complications you're not considering. JWTs are, by and large, just an inferior spec with too many brittle edges. You need to be really careful to properly implement JWTs in your environment. You're much better off either sticking to rich session tokens or using something like Macaroons. P.S., not only is the phrase "black" list steeped in a history you may not realize you're invoking, but it's much less precise than the term "stop list". Please do consider this.

weego 8y ago
Ultimately the reason JWT works for people regardless of these flaws is that almost no one ever uses it in an environment where it scales past the point that something like a blacklist lookup is a crippling flaw in the infrastructure.
- KirinDave 8y ago
  I wish this were true, but I've seen JWT deployed at some large shops with terrible technical and security outcomes and everyone seems baffled how a spec could be bad. It's unfortunate. P.S., while unrelated to my technical argument, please see my postscript above.
foxhill 8y ago
> not only is the phrase "black" list steeped in a history you may not realize you're invoking nonsense. > but it's much less precise than the term "stop list" tenuous. the term blacklist has existed since at least the 1600s[1]. i would be surprised if its meaning was not well understood. [1] - https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Blacklisting
mgraczyk 8y ago
> 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!

weego 8y ago

Ultimately the reason JWT works for people regardless of these flaws is that almost no one ever uses it in an environment where it scales past the point that something like a blacklist lookup is a crippling flaw in the infrastructure.

KirinDave 8y ago
I wish this were true, but I've seen JWT deployed at some large shops with terrible technical and security outcomes and everyone seems baffled how a spec could be bad. It's unfortunate. P.S., while unrelated to my technical argument, please see my postscript above.

foxhill 8y ago

> not only is the phrase "black" list steeped in a history you may not realize you're invoking nonsense. > but it's much less precise than the term "stop list" tenuous. the term blacklist has existed since at least the 1600s[1]. i would be surprised if its meaning was not well understood. [1] - https://en.wikipedia.org/wiki/Blacklisting https://en.wikipedia.org/wiki/Blacklisting

mgraczyk 8y ago

> 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!