this post was submitted on 10 Jul 2023
3280 points (99.3% liked)
Lemmy.World Announcements
29057 readers
6 users here now
This Community is intended for posts about the Lemmy.world server by the admins.
Follow us for server news ๐
Outages ๐ฅ
https://status.lemmy.world/
For support with issues at Lemmy.world, go to the Lemmy.world Support community.
Support e-mail
Any support requests are best sent to info@lemmy.world e-mail.
Report contact
- DM https://lemmy.world/u/lwreport
- Email report@lemmy.world (PGP Supported)
Donations ๐
If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.
If you can, please use / switch to Ko-Fi, it has the lowest fees for us
Join the team
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If a valid browser token gets stolen like in this case, then MFA won't do much good because the stolen token will already have been authenticated. Linus Tech Tips experienced the same thing recently, you can check out their channel.
That makes sense, thanks so much - there's a few good explanations here which really help! Would it be right in saying that all affected servers should be logging off all users - some have but not sure if all.
The fix is to force the use of a new JWT encryption key which--when set--would immediately invalidate all existing user cookies, forcing all users to relogin.
Lemmy has a few weaknesses related to their use of JWT in cookies that need to be addressed... The biggest one being that they use the same secret key for all user cookies (every user should have their own unique session key). I'm pretty sure that if they implemented that the scope of this vulnerability would be drastically reduced (but I haven't looked at the precise mechanism of the vulnerability yet).
They also need to provide tools in the GUI for admins and users to invalidate all issued sessions (cookies) and a mechanism for regularly rotating session secrets (the cookie currently lasts for a year and even if the session token gets regenerated it'll still use the same secret).
They also need to make the expiration times configurable so that security-focused servers can set short expiration times. Related, they need to force the use of unique secrets for every session (even if it's the same user using different devices/apps).
I guess that would depend on the specific case. If you physically went on my computer to steal my token or infected my computer with a virus to do it then we can assume that no other tokens have been compromised. But if the malicious actor has managed to steal tokens from the actual server (which seems to be the case here) and not the client then yes, as the admin I would certainly require that everyone log in again as a safety measure.