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.

[beantaco]

I'm not sure Signal requires the keyring, but does use it if available. Not sure.

That's my understanding too.

I recommended that the GNOME keyring be added as a "recommends" or "suggests" dependency, not a "depends" dependency, because the keyring is not required.

Maybe the Debian package dependency recommendation should be:

• Add the GNOME keyring package (libsecret-1-0?) as a "recommends" dependency to signal-desktop.
• If Signal Desktop's encryption also works for KDE (safeStorage API: kwallet, kwallet5, kwallet6), add those corresponding packages as an OR dependency with the GNOME keyring package.

[beantaco]

I found some relevant links in case they may be useful.

• pull request #6849
• pull request #6933
• Electron safeStorage API
• What is libsecret?

I didn't know about the Twitter drama and negative media coverage against Signal until after I created this issue 😅 I think some of the criticism and comparisons with other apps were exaggerated and unfair, and while Signal felt an urgent need to implement something, I would have liked to see a better though-out solution to encrypting Signal Desktop users' data.

[beantaco]

@ayumi-signal Is it safe to switch from using the GNOME keyring (gnome-libsecret) to plaintext key (basic), and vice-versa, using the --password-store option without risk of losing data?

[ayumi-signal]

Regarding dependencies, there are several options and commonly the keyrings associated with GNOME and KDE and we don't feel it's needed to recommend it in the deb package.

As for changing encryption keyring backends, we don't currently support migrating back to plaintext so it's necessary to run the keyring backend (and if you change desktop env, it should be possible to run say gnome-libsecret on KDE). However if you started on basic then you can encrypt it by specifying gnome-libsecret or kwallet or kwallet5. In any case, data is never lost but it may take effort to recover the key.

In theory it's possible to use the keyring utility to find the electron safeStorage key, then use that to decrypt the signal db encryption key as stored in signal's config.json encryptedKey, then specify it as the key param in config.json. We are working on improvements here.

[beantaco]

From some time onwards, canceling login keyring unlock multiple times before launching Signal stopped working. I got an error about the database. From the look of it, the login keyring on my system got unlocked without my knowledge and permission at some point, then when I launched Signal I stopped getting prompted for the login keyring password.

As I previously commented, one option for me is just to keep using the login keyring. However, I'm not committed at this point and wasn't happy that use of the login keyring was forced upon me. One reason I have against using the login keyring is it could lead me to lose access to my data whenever reinstalling the operating system or changing devices.

So, I reversed it using a crafted config.json. I happened to have a backup of my Signal data directory, which contained the key in plaintext. I grabbed the key, removed "encryptedKey" then added "safeStorageBackend": "basic_text". (Note: If "encryptedKey" exists, Signal would throw an error "Can't decrypt database key".)

{
  "key": "0123...cdef",
  "safeStorageBackend": "basic_text"
}

To be sure, I added the --password-store=basic command line option.

This works for now, but will this likely break in the future?

I imagine this could stop working if/when legacyKeyValue (corresponding to "key" in config.json) is removed from function getSQLKey in app/main.ts or some other change to the function is made.

Assuming the login keyring prompt is by design and Signal is sticking with database encryption using the login keyring, the only thing for Signal developers to do at this point is:

• Add relevant login keyring dependencies to the Debian package. rejected
• Show a prompt to the user about database encryption.
• Add a support page that explains encryption using the login keyring.

[therentabrain]

I'm using Windows but the principles are very similar. I don't want to encrypt my key, permanently marrying it to my OS install on this hardware and my user account. And I do use my own encryption already.

Also, if I'm not mistaken, I won't be able to open and work in my own sqlite db with this change.

Unfortunately, neither "safeStorageBackend": "basic_text" nor --password-store=basic seem to have any effect at all for me. Any advice? I can create a new thread if that's better, but it seems directly connected.

[beantaco]

Based on my understanding of the commit that added database encryption, it looks like Signal Desktop on Windows/macOS will always (unless somehow a keyring doesn't exist?) use the Windows/macOS keyring to encrypt the database, and ignores the value corresponding to "safeStorageBackend".

[vegantostada]

If you need to move data between computers, the encrypted key can be temporarily decrypted if you run this code in Electron Fiddle: https://gist.github.com/vegantostada/a535f878056078a6659e98a4e33f25f8 Just make sure you don’t start the app in between or the key is going to get encrypted again.

[therentabrain]

I think this re-creates the old-style unencrypted 'key' in config. Do we think that the old style 'key' will persist in being useful? I assumed it will be removed eventually.

[beantaco]

Not knowing the Signal team's intentions, I think it could still go either way, but I get the feeling that the unencrypted key will more likely be phased out to the extent possible than remain in place indefinitely. The new code looks like Signal Desktop's database encryption is in a one-way transition state from using the unencrypted key (legacyKeyValue or "key") to using the encrypted key (modernKeyValue or "encryptedKey").

For the keyring-based encryption to be effective, the unencrypted key must be purged from config.json, or else the encryption would offer no protection. The current version of Signal Desktop, if no encrypted key exists and a keyring is available, removes the unencrypted key and adds the encrypted key.

For Linux, I think it's likely that Signal Desktop will maintain support for the unencrypted key because a Linux operating system might not have a keyring, but it's also possible that Signal Desktop will become dependent on access to a keyring. For Windows and macOS, which always have a keyring I presume, I think support for the unencrypted key will get phased out.

[beantaco]

@ayumi-signal Thank you for addressing this issue. I think database encryption is a good idea. However, I was lucky to discover this problem just days before I reinstalled my operating system. Had credentials inside my previous login keyring were needed without my knowledge, I would have permanently lost access to my prior Signal data.

I think this issue can be closed. I wanted to know why the login keyring password prompt appears and what to do about it, and now we know that database encryption has been added and how it works. Related problems and action points raised above can be addressed elsewhere.

[kode54]

You can also migrate the key between backends, in case you don't know how to create it manually, by setting safeStorageBackend to the backend you want to switch to, and running that javascript/electron snippet to decrypt your key with the old backend using the correct --password-store option with electron.

Maybe use that snippet and decrypt your key if you ever intend to migrate your storage to another machine or reinstall your OS and keep a backup of Signal? Just be sure to encrypt the config.json file you keep, or your data will be insecure.

[bsd-source]

I'm using Manjaro XFCE4 Release 24.0.7. If you installed signal-desktop v7.16.0 or greater the following command works to avoid having to unlock the default keyring everytime signal-desktop starts:

signal-desktop --password-store=basic

[lefty06]

Hi Everyone,

In the past couple of linux signal desktop releases (Signal Desktop 7.24.1), this issue started to pop up, the only work around i found by chance is illustrated in the attachment.

• OS: Linux Mint Victoria 21.2 Cinamon

• Symptoms:

  • When opening Signal desktop a pop up shows up to and asks for a the logging keyring three times despite cancelling each time.
  • When the pop up disappears after cancelling a signal desktop error pops up reporting a DB error.

• Workaround:
  When you access the password and keys area and you unlock it by pressing the button and typing in your user pwd, signal desktop starts working again....

I did not dare deleting any of they keys, none of them are related to Signal Desktop but the first keyring pop up shows up every time Chromium is updated it seems.

Hopefully some day there will be a safe way to recover from this situation and why not exporting all signal desktop contents in a graceful manner.
Thanks

linux_mint_signal_desktop_workaround.pdf

[minosimo]

If you need to move data between computers, the encrypted key can be temporarily decrypted if you run this code in Electron Fiddle: https://gist.github.com/vegantostada/a535f878056078a6659e98a4e33f25f8 Just make sure you don’t start the app in between or the key is going to get encrypted again.

I tried using this but get an error during decryption:

The console logs

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

five times. After the Flathub update here flathub/org.signal.Signal#723 it would be a huge help if it turns out there's a way to recover the key!

[OnkelArmus]

I just found out that signal encrypts its database as soon as this kwallet nonsense is activated. It does so without any consent or even give information on it. I was just experimenting with the feature and decided against it, because it is extremely unsecure and leads to a false sense of security. Also why is it a chromium key? Why isn't it listed as a Signal key? And why can't I go back to as it was before? The integration of encryption in Signal desktop is as bad as it can get top to bottom.

[richardh538]

After upgrading to Ubuntu 24.10, I encountered similar issues as described above. What resolved the problem for me was Signal Desktop broken after plasma6 upgrade