Login keyring password prompt after upgrading to 7.16.0

[beantaco]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

After upgrading to 7.16.0, I see a login keyring password prompt.

The login keyring did not get unlocked when you logged into your computer.

Signal doesn't launch until the prompt goes away, but I can hit the cancel button multiple times to make that happen.

This issue has existed before (#5914).

1. What is the cause of the issue?
2. What should users do in the meantime?
3. If needed, when will Signal developers release a fix?

Steps to reproduce

1. Attempt to launch Signal.

Expected result

Signal launches immediately.

Actual result

The login prompt appears, and Signal does not launch.

Screenshots

No response

Signal version

7.16.0

Operating system

Debian based

Version of Signal on your phone

No response

Link to debug log

No response

[s38b35M5]

Can confirm. It would seem that a Chromium entry in the keyring is being used to lock the database, unlike whatever was being done before.

I use auto-login as my root partition is a luks encrypted partition, and I am not interested in logging in twice on boot, so the keyring starts unlocked. That's fine, except, Signal never needed access to the keyring before...

If I don't need to enter a password to use Signal, the prompt to access my keyring is certainly a throw-off.

Also, very disappointed to learn Signal is even using Chromium for anything at all, given the demographic of users.

[beantaco]

I never use the keyring too. When I was presented with the keyring password prompt, I didn't know what I should do. Being prompted to enter a password for an unknown reason is discomforting, I thought it could be a scam.

I haven't studied the issue enough to understand what is happening, but an issue with the same symptom has existed in the past. #5914 might help. It seems obvious to me that Signal doesn't need an unlocked login keyring, but for whatever reason it started making requests.

[ayumi-signal]

Recently we implemented the electron safeStorage API (commit: e87eaff) to encrypt the local DB encryption key which protects signal data at rest. This electron feature relies on the OS to encrypt secrets, and a password prompt may be shown by the OS to unlock the local keyring so our app can use it.

Generally after interactive login the keyring should be unlocked and there shouldn't be a prompt. However if the display manager is setup to auto-login without a password, the keyring may not be unlocked. More info: https://wiki.archlinux.org/title/GNOME/Keyring

There are ways to hide this password dialog that make security tradeoffs:

• Start signal with --password-store="basic": On Linux, stores the DB encryption key in plaintext.
• Auto-unlock the keyring by setting a blank password. This also skips OS encryption of the DB encryption key.

As this is an OS level behavior, the best we can do is to show a prompt the first time and provide a support page to explain this behavior.

[s38b35M5]

* Start signal with `--password-store="basic"`: On Linux, stores the DB encryption key in plaintext.

This has no effect for me, and still prompts to unlock my keyring.

* Auto-unlock the keyring by setting a blank password. This also skips OS encryption of the DB encryption key.

I believe the keyring still serves a purpose and disabling it completely by setting a blank password for a problem only presented by Signal would be a problem for many. It still protects authenticated sessions in apps and the browser, and much more.

As this is an OS level behavior, the best we can do is to show a prompt the first time and provide a support page to explain this behavior.

Can the app not present an optional DB encryption choice in the settings for users who feel that the previous method (that worked for how many years?) was the right balance of security and convenience? Again, if the application never prompts for a password, it is counterintuitive that it would ever touch your keyring.

If Signal must continue this practice of lean features to avoid code bloat (ie., not adding options to avoid behavior like this), then why not introduce a stage of linking the app where a secure DB encryption key is overtly/explicitly created and based on something derived from the linking/pairing process with the fully-secure and authenticated mobile device? That doesn't solve the problem of the superfluous keyring unlocking stage for auto-login users, but it would seem to at least justify this access that seems to be so important to the devs.

Honestly, I believe the users with the threat model to be hyper-concerned about the state of the DB at rest on their PC probably aren't installing the app in the first place. The risk is too high for those who need to worry about protecting access to their messages, and the inconvenience is unwarranted to the rest.

[trevor-signal]

* Start signal with `--password-store="basic"`: On Linux, stores the DB encryption key in plaintext.

This has no effect for me, and still prompts to unlock my keyring.

This would be expected if you've already entered your password once when prompted. In that case you should have an entry both for key and encryptedKey in ~/Signal Desktop/config.json. If you delete the value for encryptedKey and start the application again with --password-store="basic", I would expect you not to be prompted. Please let us know.

[beantaco]

Thank you for the explanation @ayumi-signal.

I agree with the idea of keeping Signal data encrypted at rest.

However, like what @s38b35M5 suggested, I believe the Signal application itself should manage encryption at rest and show this feature in the settings. I believe Signal's data should be locked/unlocked as and when needed by the Signal application and user, not be determined by something outside such as GNOME keyring. I don't know of any application that uses GNOME keyring; and GnuPG, SSH and password managers lock/unlock keys as and when needed using their own methods.

Furthermore, GNOME keyring is affected by security vulnerability CVE-2018-19358. ArchLinux documentation says that any application can easily read any secret from the keyring once it is unlocked. This remains unfixed (Ubuntu, Debian), presumably because the GNOME project disagrees with the vulnerability and therefore refused to fix it.

My take on this is, the security gain of encrypting Signal data at rest using a key stored in an exploitable keyring is minimal.

[beantaco]

I forgot to mention, I didn't see any announcement of this encryption at rest (or any other change or any changelog) when I updated Signal or before I attempted to open Signal, before I was prompted for a password. Some users were probably surprised by this, definitely me.

I checked the release notes, but they contain just a one or two sentence paragraph that's not very informative. In my opinion they should contain at least a changelog.

[s38b35M5]

* Start signal with `--password-store="basic"`: On Linux, stores the DB encryption key in plaintext.

This has no effect for me, and still prompts to unlock my keyring.

This would be expected if you've already entered your password once when prompted. In that case you should have an entry both for key and encryptedKey in ~/Signal Desktop/config.json. If you delete the value for encryptedKey and start the application again with --password-store="basic", I would expect you not to be prompted. Please let us know.

I uninstalled and removed my ~/.config/Signal... folder to remove any old config. As I was experimenting, I attempted to install the previous version of signal-desktop at the time (7.15.x) and received a DB upgrade in the future error, which alerted me to the remaining config. After reinstall from scratch and using the --pasword-store=basic option, I am not prompted for a password.

I think this will work for some users, but as it requires being aware of this caveat of recently added keyring use to store the key for the DB, it may be most helpful to present users with an option on initial install or first run that explicitly calls this out, and the same on upgrade from <7.16.x that will be surprised.

Yes, many already unlock their keyring on sign in, but Signal using the keyring is new behavior that some are not prepared for, and losing access to your own message database (even if just on desktop) through unintended actions of previously signal-unrelated keyring may be more worrisome to some than the prospect of unauthorized access to the message DB at rest.

Food for thought.

[lucasmz-dev]

I don't know of any application that uses GNOME keyring; and GnuPG, SSH and password managers lock/unlock keys as and when needed using their own methods.

A lot of apps actually do, Chromium for instance, and anything based in it usually. Element, Bitwarden as an example. I still can't tell if Firefox does but it doesn't seem like it.

However, like what @s38b35M5 suggested, I believe the Signal application itself should manage encryption at rest and show this feature in the settings.

Even with the issues with the keyring there, which seem to depend on higher access so (?) don't know much about that anyway, is that it provides security for users without full disk encryption enabled, which is a lot of people, I do because of apps that don't use it like Signal did previously. For Signal to manage encryption itself, it'd probably have to add a prompt for a password which just adds complexity when the OS keyring is already available and misses the point of protecting users who aren't aware. Even if there are issues with the Linux implementation of keyring, it is better than storing the key in plaintext.

At the moment, it just seems your keyring is misconfigured. I believe I've had this issue before not sure how when trying to switch DEs and went to KDE, but yeah.

[beantaco]

I guess Chromium and everything based on it uses the GNOME keyring. Firefox doesn't.

For Signal to manage encryption itself, it'd probably have to add a prompt for a password which just adds complexity when the OS keyring is already available and misses the point of protecting users who aren't aware.

I see your point @lucasmz-dev about not adding complexity when an operating system keyring is available. However, this assumes the operating system has a keyring (some people might uninstall it) and the user is happy to use it.

I believe added complexity of an unlock prompt in Signal Desktop is warranted. For comparison, Signal on Android asks for a password, and so do GnuPG, SSH, full disk encryption and password managers, to keep secret material safe except while in use. I think a keyring that unlocks all its secrets upon login is not a good idea. Users who can't tolerate a password prompt can choose either not encrypt their data (in Signal Desktop's case the pre-7.16.0 situation) or unlock using a hard-coded key or hardware key.

However, in my case, my GNOME keyring would get unlocked when I launch Signal (not at login) and my GNOME keyring would contain only the Signal key (not a vast amount of secrets), but I imagine the GNOME keyring will remain unlocked after I close Signal.

I won't configure my GNOME keyring to unlock upon login, so my understanding is I basically have two options:

1. Bypass the password prompt using --password-store=basic and leave my Signal data in plaintext (the pre-7.16.0 situation).
2. Configure the GNOME keyring to encrypt my Signal data and then unlock it when launching Signal.

For option 2, should I enter my operating system user's password at the password prompt? I guess I should backup ~/.config/Signal before encrypting my Signal data.

[beantaco]

@ayumi-signal I recommend adding gnome-keyring as a "recommends" or "suggests" dependency of the signal-desktop Debian package, so that people will know to install gnome-keyring. Please see my later comment. What do you think?

[lucasmz-dev]

I'm not sure Signal requires the keyring, but does use it if available. Not sure. Community flatpak version does not seem to use it yet but runs fine.