Cybersecurity

5626 readers

132 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Be respectful. Everyone should feel welcome here.
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
No Ads / Spamming.
No pornography.

Community Rules

Idk, keep it semi-professional?
Nothing illegal. We're all ethical here.
Rules will be added/redefined as necessary.

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 1 year ago

MODERATORS

kid@sh.itjust.works

Lanky_Pomegranate530@midwest.social

Signal under fire for storing encryption keys in plaintext (stackdiary.com)

submitted 4 months ago by kid@sh.itjust.works to c/cybersecurity@sh.itjust.works

15 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Sethayy@sh.itjust.works 9 points 4 months ago (1 children)

Yeah fuck security in layers, my first layer is 100% bulletproof so I got no reason to worry

[–] BearOfaTime@lemm.ee 3 points 4 months ago* (last edited 4 months ago) (1 children)

Exactly, which is why your drives should be encrypted.

Once you lose physical control of a device, all bets are off, drive encryption at least slows down attackers significantly.

I have far more sensitive, and a greater volume of data, on the drive than just comms.

[–] Sethayy@sh.itjust.works 4 points 4 months ago* (last edited 4 months ago) (2 children)

Drive encryption wouldn't do anything to mitigate this though? A process running on your PC needs access to your drive, and so with the current setup you have either the option to trust 100% every software with your signal encryption keys, or to simply not use them.

Seems like a pretty big security flaw that we have actual solutions to.

You could maybe form a hackey way to allow only the signal process to an encrypted FUSE filesystem that decrypts its own keys on the fly, but again there's already ways to do this in software that isn't like using a wrench to plug a leak. (and this setup would just have it's own set of keys that need to be protected now, probably by a traditional method like kwallet)

[–] douglasg14b@programming.dev 2 points 4 months ago (1 children)

I mean... Every serious operating system already has some form of keyring feature right?

[–] Sethayy@sh.itjust.works 4 points 4 months ago

Ie. what signal should be using, yet isnt

[–] sun_is_ra@sh.itjust.works 1 points 4 months ago (1 children)

there is SELinux which give more fine tuned permissions for each app but it was too complicated for me

[–] Sethayy@sh.itjust.works 2 points 3 months ago

And if you're using SELinux as a kwallet/keyring replacement, you're using it wrong (but again security in layers doesn't stop you from using both)