00:00 Introduction 5:08 HTTP-Cookies 06:49 Session-IDs to add more trust to cookies 09:20 Problems with Session-IDs when having multiple servers in parallel - shared cache - distributed cache - sticky sessions 15:29 Json Web Tokens 15:53 "Cockies" vs "Session ID" vs "JWTs" 16:43 Two kind of tokens - "by Reference" - "by value" 17:45 Authentication and Authorization with a JWT as Cockie 19:20 Structure of JWTs 26:13 Benefits of JWTs - simple load balancing (no state) 28:29 Signatures - symetric - asymetric 29:49 OAuth2 and OpenID Connect 31:26 Drawbacks of JWTs - Revokation - Same as SessionId - XSS Attacks 41:32 Other JWT applications - multi-part user forms - confirmation emails
He said that the drawback of JWT stored in cookies flagged as HTTPOnly is that you cant read the payload from JS. There is a simple solution for this problem. You can split the JWT into 3 parts (header, playload and the signature). Then you can set two cookies. The first one flagged as HTTPOnly will contains header + signature and the second one will contains only the payload and will not be flagged as HTTPOnly so you can read it from JS. XSS attacker can read or modify the payload, but thats ok, because he cannot access the signature, so the modified token will be invalid.
@@titocito still doesn't solve the problem| the hacker can brute force all the common algos and hit a valid jwt he doesn't need to modify the jwt if he wants to impersonate the user
@@darshandhabale143 how is that? I don't get the vulnerability you are pointing. how can a XSS attacker impersonate the user if it has no access to the signature (assuming that brute forcing the signature is a very expensive and slow operation)? Or are you are talking about that vulnerability when the server starts trusting algorithms defined by in the JWT payload? To fix it make the server never trust the "alg" defined in the JWT and use a hardcoded one check it against a list of trusted algs which exclude the "none" one.
Amazing explanation of JWT and session persistence. One question though: At 43:10, you suggested using sessionID at API gateway. Does this mean that the API gateway will have some storage mechanism? If yes, then won't it have the issues that you had mentioned at 10:05 ?
What prevents an attacker from reading my local storage, retrieving the sync token and then submitting a form with the cookie + that sync token and perform a CSRF attack?
I'm not sure if I get this right, but here is my consideration (using the Twitter example): In a CSRF attack the attacker can use the twitter cookie. The attacker cannot read it but it will automatically be sent with the request to the twitter server (see 36:44). At the same time, since the attack is performed on another web app, the attacker has no access to the local storage of twitter, so he can't read the authenticity-id. If the attacker manages to run malicious code in the twitter application (via library or an XSS attack), the attacker get access to the local storage, therefore to the authenticity-id. However, the attacker won't be able to read the cookie because of the httpOnly flag. But in the second case, I don't see what prevents the attacker to post something on twitter on behalf of the victim.
There are two potential problems with this approach in my humble opinion..... Firstly using JWT means now I have a (JSON) data structure readily available on my client machines, in plain text (well base64 which is tantamount to plain text,) that perhaps contains sensitive application information that was previously only available to my web/application server. Secondly doesn't this violate SoC. Why should my clients even care about application state or contextual data? Shouldn't thin clients like web browsers be completely stateless and really only care about rendering and presenting TRANSIENT data returned over the scope of a GET/POST request. Perhaps I'm missing something, best practices seem to shift so fast in application architecture and thus it is entirely possible that the approach I've outlined is now considered to be a bit antiquated.
Very nice, very clear, perfect. And as neighbour (i'm french), i like your french accent (but mine from south of french is also much more incredibly nicer, i promise). :)
@ua-cam.com/video/67mezK3NzpU/v-deo.html ,cant the attacker access the local storage get the csrf and then send a request on behalf of the authenticated user ?
thanks for the amazing explanation on JWT. I have question here. suppose say the expiration of the JWT token is 15mins after its creation but the user logout/close browser just after 5 mins. Now, I need to destroy the created token. how can I do that. any kind of help is appreciated.
My solution would be to delete the cookie instead. The token will still be valid, but the users browser won't send it anymore. Again, this wouldn't be a good solution for banking software, but for the "right" user experience it would suffice, if the token was not stolen in the mean time. If you want to prevent that beeing an issue you will need to implement a blacklist (at least as far as I know).
You need to play with the signing secret used to sign the JWT token, a naive implementation would be to generate a user specific secret and a server specific secret, so to sign the jwt you combine both the secrets and sign it, so now if you need to revoke the access for a particular user you change the user specific secret in the datastore or if you want to revoke all the JWTs used in the entire system from working you just change the server secret.
There does not seem an universal way to solve the problem. Tokens by nature are persistent until their expiration. To revoke them you need to workout on server end as well, check the token at each request against database for instance.
That's funny. I also bought my first computer in 1994 - a Quantex P90. That was close to the state of the art for Wintel machines at the time. Not many weeks later Slackware was installed. :-)
Thanks for the simple explanation and entertaining presentation. It would be nice if you can clarify the following @ 29:30 you are talking about a "Security Provider" holding a private key in one of the servers and others holding the public key. Initially i thought that the info from all other servers will be served after an authentication check with the Security provider server BUT then i saw there are no connections between the servers themselves to the Security Provider. So 1. Is this some form of content segregation across servers where the authenticated users content and unauthenticated users content are kept and served separate to distribute the load ? If not can you kindly explain why there are no connection between the servers with the public key to the server with the private key ? 2. If all other servers rely on the Security provider server to let them know whether or not to server the content, then wont the Security Provider server will become the Single Point of Failure ? 3. Having a public key in cookie and storing the private key in the server to authenticate, How different is this from storing a session ID in the cookie and storing the session ID reference in the server to authenticate ? Pardon me if my questions are too basic (and for the long post), really appreciate if you can shed some light on these for my better understanding
Public keys are only used to check the signature, you could literally save them in a public url with no problem. Only have a problem if the private key is leaked.
It's amazing how the people reinvent the wheel with JWT claims and cookies. Setting the Path, Domain, Session ID already exist in RFC-7519 (iss, sub, aud, jwi).
even though session can be saved from single point of failure using jwt, an application needs to save lots of internal data in databases. what if they fail? If you can make them fail proof then there is no problem for normal sessions and no need for jwt
Finally someone does know how JTW's should be used and is not talking shit about it like dozens of others here... thx Hubert
00:00 Introduction
5:08 HTTP-Cookies
06:49 Session-IDs to add more trust to cookies
09:20 Problems with Session-IDs when having multiple servers in parallel
- shared cache
- distributed cache
- sticky sessions
15:29 Json Web Tokens
15:53 "Cockies" vs "Session ID" vs "JWTs"
16:43 Two kind of tokens
- "by Reference"
- "by value"
17:45 Authentication and Authorization with a JWT as Cockie
19:20 Structure of JWTs
26:13 Benefits of JWTs
- simple load balancing (no state)
28:29 Signatures
- symetric
- asymetric
29:49 OAuth2 and OpenID Connect
31:26 Drawbacks of JWTs
- Revokation
- Same as SessionId - XSS Attacks
41:32 Other JWT applications
- multi-part user forms
- confirmation emails
thank you very much for your effort!
Thanks
41:32 Other JWT applications
- multi-part user forms
- confirmation emails
@@micalevisk thanks, have added this
He said that the drawback of JWT stored in cookies flagged as HTTPOnly is that you cant read the payload from JS. There is a simple solution for this problem. You can split the JWT into 3 parts (header, playload and the signature). Then you can set two cookies. The first one flagged as HTTPOnly will contains header + signature and the second one will contains only the payload and will not be flagged as HTTPOnly so you can read it from JS. XSS attacker can read or modify the payload, but thats ok, because he cannot access the signature, so the modified token will be invalid.
That's veery clever, thank you!
@@titocito still doesn't solve the problem|
the hacker can brute force all the common algos and hit a valid jwt
he doesn't need to modify the jwt if he wants to impersonate the user
@@darshandhabale143 how is that? I don't get the vulnerability you are pointing.
how can a XSS attacker impersonate the user if it has no access to the signature (assuming that brute forcing the signature is a very expensive and slow operation)?
Or are you are talking about that vulnerability when the server starts trusting algorithms defined by in the JWT payload? To fix it make the server never trust the "alg" defined in the JWT and use a hardcoded one check it against a list of trusted algs which exclude the "none" one.
This is the best JWT explanation I've seen. I love your inclusion of CSRF as well.
Amazing explanation of JWT and session persistence.
One question though: At 43:10, you suggested using sessionID at API gateway. Does this mean that the API gateway will have some storage mechanism? If yes, then won't it have the issues that you had mentioned at 10:05 ?
What prevents an attacker from reading my local storage, retrieving the sync token and then submitting a form with the cookie + that sync token and perform a CSRF attack?
You cant do this from another site if you set your cookie to have httpOnly attribute, hence attacker site wont get the cookie itself
Atul R so if the attacker can’t use the cookie, what’s the need of the extra item in thr local storage?
I'm not sure if I get this right, but here is my consideration (using the Twitter example):
In a CSRF attack the attacker can use the twitter cookie. The attacker cannot read it but it will automatically be sent with the request to the twitter server (see 36:44).
At the same time, since the attack is performed on another web app, the attacker has no access to the local storage of twitter, so he can't read the authenticity-id.
If the attacker manages to run malicious code in the twitter application (via library or an XSS attack), the attacker get access to the local storage, therefore to the authenticity-id. However, the attacker won't be able to read the cookie because of the httpOnly flag.
But in the second case, I don't see what prevents the attacker to post something on twitter on behalf of the victim.
Good question I was hopping to someone ask it. Hopefully someone in te comments can answer.
Yes I support this. I don't understand as well.
- jwt cannot be compared to cookies, but can be to session id: session id - by reference, credit card, jwt - by value, banknote
need to see it at 1.25x atleast, but good talk :)
1.75 is better :)
2x is even better @@shef9192
nice explaination, which tools you used to create all the diagrams?
I would like to know this as well!
author has no time to answer
Is this still valid in 2023 or should i consider any other vulnerability? Thanks and great lecture
There are two potential problems with this approach in my humble opinion.....
Firstly using JWT means now I have a (JSON) data structure readily available on my client machines, in plain text (well base64 which is tantamount to plain text,) that perhaps contains sensitive application information that was previously only available to my web/application server.
Secondly doesn't this violate SoC. Why should my clients even care about application state or contextual data? Shouldn't thin clients like web browsers be completely stateless and really only care about rendering and presenting TRANSIENT data returned over the scope of a GET/POST request.
Perhaps I'm missing something, best practices seem to shift so fast in application architecture and thus it is entirely possible that the approach I've outlined is now considered to be a bit antiquated.
Very nice, very clear, perfect.
And as neighbour (i'm french), i like your french accent (but mine from south of french is also much more incredibly nicer, i promise).
:)
Awesome talk, is this presentation slides available somewhere online?
Merci pour cette présentation : the best JWT explanation and security issues that one can have.
Great explanation on the advantage of using JWT token vs Session IDs.
Very nice lesson
@ua-cam.com/video/67mezK3NzpU/v-deo.html ,cant the attacker access the local storage get the csrf and then send a request on behalf of the authenticated user ?
thanks for the amazing explanation on JWT.
I have question here. suppose say the expiration of the JWT token is 15mins after its creation but the user logout/close browser just after 5 mins. Now, I need to destroy the created token. how can I do that. any kind of help is appreciated.
My solution would be to delete the cookie instead. The token will still be valid, but the users browser won't send it anymore. Again, this wouldn't be a good solution for banking software, but for the "right" user experience it would suffice, if the token was not stolen in the mean time. If you want to prevent that beeing an issue you will need to implement a blacklist (at least as far as I know).
You need to play with the signing secret used to sign the JWT token, a naive implementation would be to generate a user specific secret and a server specific secret, so to sign the jwt you combine both the secrets and sign it, so now if you need to revoke the access for a particular user you change the user specific secret in the datastore or if you want to revoke all the JWTs used in the entire system from working you just change the server secret.
There does not seem an universal way to solve the problem. Tokens by nature are persistent until their expiration. To revoke them you need to workout on server end as well, check the token at each request against database for instance.
can anyone help me how to implement jwt in microservice architecture?
amazing
That's funny. I also bought my first computer in 1994 - a Quantex P90. That was close to the state of the art for Wintel machines at the time. Not many weeks later Slackware was installed. :-)
Thanks for the simple explanation and entertaining presentation.
It would be nice if you can clarify the following
@ 29:30 you are talking about a "Security Provider" holding a private key in one of the servers and others holding the public key. Initially i thought that the info from all other servers will be served after an authentication check with the Security provider server BUT then i saw there are no connections between the servers themselves to the Security Provider.
So
1. Is this some form of content segregation across servers where the authenticated users content and unauthenticated users content are kept and served separate to distribute the load ? If not can you kindly explain why there are no connection between the servers with the public key to the server with the private key ?
2. If all other servers rely on the Security provider server to let them know whether or not to server the content, then wont the Security Provider server will become the Single Point of Failure ?
3. Having a public key in cookie and storing the private key in the server to authenticate, How different is this from storing a session ID in the cookie and storing the session ID reference in the server to authenticate ?
Pardon me if my questions are too basic (and for the long post), really appreciate if you can shed some light on these for my better understanding
Active subtitles recommended
Might as well parler en français lol
This guy talks like Stan Wawrinka.
Wow, did not remember the level codes of Lemmings
Really brilliant talk!
Very clear. Thank you!
94' PC and screenshot from Windows XP - not cool ;)
Great. Well explained.
link to downloadable copy of slides pls?
this is amazing
I didn't understand the use of asymmetric key. If the public key is leaked, I could still fake identities?
Do a quick Google on how PKI (public key infrastructure) works and it will answer all your questions about the private and public key use.
Public keys are only used to check the signature, you could literally save them in a public url with no problem. Only have a problem if the private key is leaked.
95% of the room played Lemmings, really ?
Yeah, I would say more than 90% of the room voted yes ;-)
I can confirm that. I only wish I had taken a picture.
thats so cool i hardly know anyone who played it too. :(
awesome. thank you very much.
nice
really interesting. thanks for sharing
It's amazing how the people reinvent the wheel with JWT claims and cookies. Setting the Path, Domain, Session ID already exist in RFC-7519 (iss, sub, aud, jwi).
Wonderful explanation .
Awesome talk, debunked a lot of misconception I had about JWT and security
Talk starts at 16th min.
Great explanation
18:42 "I'm a cookie, what do I do?"
Not much 😅
you send the cookies
even though session can be saved from single point of failure using jwt, an application needs to save lots of internal data in databases. what if they fail? If you can make them fail proof then there is no problem for normal sessions and no need for jwt
That involves paying more money for extra servers to ensure sessions are highly available. JWTs do not require this.
Why do we never start first talking about load balancer getting failed?
You have bigger issues then than the token or any other solution.
SessionID is not an issue. Apple Music Store is a stateful application and it scales.