this post was submitted on 10 Jul 2023
3274 points (99.3% liked)
Lemmy.World Announcements
29156 readers
2 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 [email protected] e-mail.
Report contact
- DM https://lemmy.world/u/lwreport
- Email [email protected] (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 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What's the difference? JWT is already cryptographically signed, but tokens were stolen. That's the issue.
No one store their PGP private key in cookies, at least I hope so.
Ideally someone wants to send signed message doesn't store the signing key in their browser, sandbox their browser even.
Imagine you have
Permission to post as [email protected]
as an object that is locked in a safe deposit box, the key isJWT token
.The key, by how it works, can be obtained by (1) knowing [email protected]'s password (+2FA token if configured) (2) have a copy of the token (3) somehow cheat lemmy.world's authentication scheme (by somehow skipping authentication or acquiring magic tool to generate random token .... etc).
What happened today is scenario (2), by a single line of JavaScript planted by hacker, and if you have access to my unlocked desktop computer, you can see and copy the key by using F12 (developer tool).
Scenario (2) can be mitigated by tying the sending computer IP to
JWT token
, but as far as I can tell lemmy.world doesn't have the option, and most of people get random new IP address every now and then because how Internet currently operates, so this feature can be very annoying.now introduce
Permission to post PGP signed message as [email protected]
as an object that is locked in a safe deposit box, this deposit box has two key slot (like a bank deposit box),JWT token
andPGP private key
.This
PGP private key
doesn't have to sit in your browser, it can be on a burner phone which it's only purpose is a APP for signing message, it can be on a USB thumb drive that is stored in your parent's basement, or usb thumb drive that sits in bank deposit box which requires a bank employee to authenticate your ID to access.........PGP private keys are harder to steal than JWTs, as they are not generally stored as a long-term cookie but briefly just to sign something. Through XSS (the vulnerability in this case), cookies are relatively easy to steal, but to steal a PGP key would require a more complex script able to steal the key at the time it is loaded in the browser (assuming the signing feature is implemented in the browser). It's a bit more sophisticated, but not totally bulletproof.
First of all, it's still possible, as you said. Second, we must always take humans into consideration. Let me explain.
Most people don't know what PGP is, thus you can sign your posts with any crap and most won't care.
Out of those who know what PGP is and how to use it, most won't be checking the posts as they will auto-assume that if it's signed - it's ok.
There will be a small minority of those who care, but they can be silenced easily through social engineering.
It is possible to integrate server side signature checks, but then again you're vulnerable when someone gains unrestricted access to your account.
The correct solution requires multiple features to be implemented.
Agree with the points on PGP and other features. I almost made a lengthier reply mentioning the signing issues, which seems appropriate now. It would not be easy, but a successful implementation would definitely need clients to automatically detect and verify signed content, due to the human issues you mention. A problem is obtaining public keys from a trusted source. Maybe it could be attached to profile information with a 2FA requirement to modify it. Just an idea. In this way, verification is not dependent on the user to perform.