Signal under fire for storing encryption keys in plaintext

Post by ghusto » Sun, Jul 07, 2024, 7:09 PM UTC

mike_hearn wrote: post #11

Credential protection in desktop apps, state of the art on each platform, July 2024 edition: -- macOS -- On macOS protecting credentials is easy and effective. You can store secrets in two places: 1. In the system keychain. The best place because the keystore database records the code signing identity of each app that creates an entry, and any other app that tries to access those credentials will trigger a permission…

> the keystore database records the code signing identity of each app that creates an entry, and any other app that tries to access those credentials will trigger a permission check by the OS

Except for the CLI, which had full access to the keychain.

Post by mike_hearn » Sun, Jul 07, 2024, 7:15 PM UTC

ghusto wrote: post #21

mike_hearn wrote: post #11

Credential protection in desktop apps, state of the art on each platform, July 2024 edition: -- macOS -- On macOS protecting credentials is easy and effective. You can store secrets in two places: 1. In the system keychain. The best place because the keystore database records the code signing identity of each app that creates an entry, and any other app that tries to access those credentials will trigger a permission…

> the keystore database records the code signing identity of each app that creates an entry, and any other app that tries to access those credentials will trigger a permission check by the OS Except for the CLI, which had full access to the keychain.

No, CLI apps also trigger access checks. Like I said, try it in your terminal using "ls". You'll find that trying to access a sandboxed container triggers a permission check.

Re: Signal under fire for storing encryption keys in plaintext

Re: Signal under fire for storing encryption keys in plaintext