5 ms·
The issue is not deleting the cookie. The issue is that the JWT can still be used as a valid session unless you have some sort of blocklist. Once you introduce
by hermanradtke 5y ago
The issue is not deleting the cookie. The issue is that the JWT can still be used as a valid session unless you have some sort of blocklist. Once you introduce a blocklist, you might as well ditch the JWT and use some opaque token stored in a table.
- axiosgunnar 5y agothe entire article could be summed up with this post tbh
- remram 5y agoIs that a problem though? Does your threat model include clients that correctly send logout requests when they're supposed to but don't delete cookies when they're told?
- colinclerk 5y agoYour application should certainly have some resolution to an account being hacked or a session token being stolen. No expiry and no denylist means an attacker can cause problems until you patch your code.
- SigmundA 5y agoNever trust the client, ever.
- remram 5y agoIf that's how you feel, don't trust them to logout when they walk away. Make those sessions short-lived and ask for the password again whenever they do something remotely sensitive.
- jfgiogktkt 5y agoYou logout on a public computer, the next user undeletes the cookie (which is just a row in a profile SQLite database).
- remram 5y agoCouldn't the previous user have rigged the app to not send the logout request, or way more plausibly installed a keylogger to get your password, which allows them to log in again at will? I'm not disagreeing with you, it just seems to only cover a very specific type of attack, if someone else can mess with software. And of course if they can't it is unnecessary.