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
@PratozTube
6 жыл бұрын
thank you very much for your effort!
@sunilsawant2621
5 жыл бұрын
Thanks
@micalevisk
4 жыл бұрын
41:32 Other JWT applications - multi-part user forms - confirmation emails
@-andymel
2 ай бұрын
@@micalevisk thanks, have added this
@mspiderv
5 жыл бұрын
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
Жыл бұрын
That's veery clever, thank you!
@darshandhabale143
7 ай бұрын
@@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
@titocito
7 ай бұрын
@@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.
@timm.6875
6 жыл бұрын
Finally someone does know how JTW's should be used and is not talking shit about it like dozens of others here... thx Hubert
@adamgm84
7 жыл бұрын
This is the best JWT explanation I've seen. I love your inclusion of CSRF as well.
@srghma
3 жыл бұрын
- jwt cannot be compared to cookies, but can be to session id: session id - by reference, credit card, jwt - by value, banknote
@Mrhennayo
7 жыл бұрын
Merci pour cette présentation : the best JWT explanation and security issues that one can have.
@michaeljean-jacques7413
7 жыл бұрын
Great explanation on the advantage of using JWT token vs Session IDs.
@jeromelanteri6469
4 жыл бұрын
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). :)
@rahulgaba
5 жыл бұрын
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 ?
@aprofromuk
6 жыл бұрын
need to see it at 1.25x atleast, but good talk :)
@shef9192
4 жыл бұрын
1.75 is better :)
@darshandhabale143
7 ай бұрын
2x is even better @@shef9192
@omrip23
5 жыл бұрын
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?
@AtulR
5 жыл бұрын
You cant do this from another site if you set your cookie to have httpOnly attribute, hence attacker site wont get the cookie itself
@thegrandmaster55
5 жыл бұрын
Atul R so if the attacker can’t use the cookie, what’s the need of the extra item in thr local storage?
@GioeleMoretti
5 жыл бұрын
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.
@HeyDan1983
4 жыл бұрын
Good question I was hopping to someone ask it. Hopefully someone in te comments can answer.
@vncntjms
3 жыл бұрын
Yes I support this. I don't understand as well.
@madhurgwa
7 жыл бұрын
nice explaination, which tools you used to create all the diagrams?
@sgtnotorious
7 жыл бұрын
I would like to know this as well!
@sunilk9760
5 жыл бұрын
author has no time to answer
@fredscholl5250
7 жыл бұрын
Really brilliant talk!
@CarloL525
3 жыл бұрын
Very clear. Thank you!
@shibinfr
3 жыл бұрын
Great. Well explained.
@johnestess5895
7 жыл бұрын
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. :-)
@manee427
Жыл бұрын
amazing
@rahulsen5584
7 жыл бұрын
Wonderful explanation .
@tintin-qu4gs
6 жыл бұрын
Very nice lesson
@daniellevanon
5 жыл бұрын
Great explanation
@mazyvan
7 жыл бұрын
really interesting. thanks for sharing
@jadsayegh6283
7 жыл бұрын
Awesome talk, debunked a lot of misconception I had about JWT and security
@vipzip8863
6 жыл бұрын
Awesome talk, is this presentation slides available somewhere online?
@shipup8454
7 жыл бұрын
awesome. thank you very much.
@contactoliverwhite
7 жыл бұрын
this is amazing
@brandondiaz901
10 ай бұрын
Is this still valid in 2023 or should i consider any other vulnerability? Thanks and great lecture
@gilesthompson4605
6 жыл бұрын
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.
@Sun0fABeach
5 жыл бұрын
Active subtitles recommended
@rohithreddyvadiyala2360
7 жыл бұрын
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.
@dreuter
7 жыл бұрын
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).
@pradeepsamuel6747
7 жыл бұрын
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.
@microtech2448
6 жыл бұрын
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.
@elnatanvazana8280
4 жыл бұрын
18:42 "I'm a cookie, what do I do?"
@Luclecool123
3 жыл бұрын
Not much 😅
@mishasawangwan6652
2 жыл бұрын
you send the cookies
@berndeckenfels
4 жыл бұрын
Wow, did not remember the level codes of Lemmings
@kamikaze3407
7 жыл бұрын
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
@tibordigana2551
4 жыл бұрын
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).
@varunshenoy532
7 жыл бұрын
I didn't understand the use of asymmetric key. If the public key is leaked, I could still fake identities?
@adamgm84
7 жыл бұрын
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.
@atif1996
7 жыл бұрын
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.
@user-tk7zn6pc5x
6 жыл бұрын
Talk starts at 16th min.
@fredpies
5 жыл бұрын
nice
@kharika5551
4 жыл бұрын
can anyone help me how to implement jwt in microservice architecture?
@evandrix
7 жыл бұрын
link to downloadable copy of slides pls?
@TomaszRychter
7 жыл бұрын
94' PC and screenshot from Windows XP - not cool ;)
@wildbakaar
7 жыл бұрын
95% of the room played Lemmings, really ?
@hsablonniere
7 жыл бұрын
Yeah, I would say more than 90% of the room voted yes ;-)
@mojavelinux
7 жыл бұрын
I can confirm that. I only wish I had taken a picture.
@minaitconcepts7298
6 жыл бұрын
thats so cool i hardly know anyone who played it too. :(
@medi7573
5 жыл бұрын
@kzitem.info/news/bejne/l22jy66BbICro4o ,cant the attacker access the local storage get the csrf and then send a request on behalf of the authenticated user ?
@nid274
7 жыл бұрын
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
@dkryptr
7 жыл бұрын
That involves paying more money for extra servers to ensure sessions are highly available. JWTs do not require this.
@spillow762
5 жыл бұрын
This guy talks like Stan Wawrinka.
@viky293
6 жыл бұрын
Why do we never start first talking about load balancer getting failed?
@jumanjimusic4094
5 жыл бұрын
You have bigger issues then than the token or any other solution.
@alexnezhynsky9707
5 жыл бұрын
Might as well parler en français lol
@carnelyve866
6 жыл бұрын
SessionID is not an issue. Apple Music Store is a stateful application and it scales.
Пікірлер: 79