Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using JWT for sessions (2016)

cryto.net

Post reply on HN
Print view View original

11–20 of 255 posts

Re: Stop using JWT for sessions (2016)

#11

Post by drinchev »

Top reason for me always was :

> You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecting a compromise. You also cannot invalidate old sessions when a user changes their password.

> You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with.

Re: Stop using JWT for sessions (2016)

#12

Post by todd3834 »

pentestercrab wrote: post #3

This JSON Web Token Security Cheat Sheet[1] or this python script[2] are both quite useful when reviewing anything using of JWTs. [1] https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_... [2] https://github.com/ticarpi/jwt_tool

Those are great! I find the OWASP cheat sheet[1] useful as well but I’m going to keep the pentesterlab cheetsheet bookmarked for easier to digest to similar data. Thanks for sharing!

[1] https://www.owasp.org/index.php/JSON_Web_Token_(JWT)_Cheat_S...

Re: Stop using JWT for sessions (2016)

#14

Post by tehlike »

drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

Re: Stop using JWT for sessions (2016)

#15

Post by anonymousJim12 »

tehlike wrote: post #14
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

How do you encode it in such a way that you can invalidate individual tokens? How do you distribute that information among your services?

Re: Stop using JWT for sessions (2016)

#16

Post by lvh »

tehlike wrote: post #14
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

So you're saying you can have sane sessions as long as you have some server-side storage? :-)

Re: Stop using JWT for sessions (2016)

#17

Post by caiob »

drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Why not just "invalidate" the client? At best, you're making your application "safe" for 900ms or whatever the expiry date is.

Re: Stop using JWT for sessions (2016)

#18

Post by [deleted] »

tehlike wrote: post #14
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

[deleted]

Re: Stop using JWT for sessions (2016)

#19

Post by zhobbs »

tehlike wrote: post #14
drinchev wrote: post #11

Top reason for me always was : > You cannot invalidate individual JWT tokens And there are more security problems. Unlike sessions - which can be invalidated by the server whenever it feels like it - individual stateless JWT tokens cannot be invalidated. By design, they will be valid until they expire, no matter what happens. This means that you cannot, for example, invalidate the session of an attacker after detecti…

Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

With this method isn't the downside that you have to invalidate all tokens, and not just the attacker's tokens?
Post reply on HN