Desktop app does not support protected storage

[DDvO]

The mobile Signal app supports protecting access using, e.g., a pattern or fingerprint.
I hope, but doubt, that this also entails sensibly encrypted data storage,
which would be based on a user-supplied secret that is not stored on the device.

The desktop app obviously does not support anything like this!

• The app does not have any access lock
• Messages are encrypted since commit 3105b77 of July 2018 using a key stored in plain next to the data
• Attachments (files, images etc.) are stored in plain

There have been multiple reports and requests in this direction since more than four 5 years -
see, e.g., #452, #1850, #1895, and #2008, but they were denied and further commenting on them was locked.
There is even a pull request #5465 provided by a user that would have solved the issue, but it was rejected.
Are you serious?

For a messenger that boasts high-grade end-to-end encryption,
this situation is not just a missing feature but a severe security flaw.

[hiqua]

See #5541.

[DDvO]

BTW, Telegram is not really better here - users can set a PIN for locking access, but this is not activated automatically (after some configurable time or so), and message data is not encrypted using it.
Threema seems to be the only messenger that offers sensibly encrypted data storage with a user-provided password, but it does not offer a standalone desktop client.

[DDvO]

In case someone questions the relevance of data encryption for the desktop client:
Personal computers usually do not use encrypted file systems, so with physical access, data can be read from the outside.
And even when using encrypted file systems and good user account protection, malware running on the system still has file-based access.
Therefore, when storing mails, classical email clients like Thunderbird do not remove encryption that has been applied to them,
and access to private keys can be protected using a passphrase not stored on the system.

[DDvO]

See #5541.

@hiqua, the reference you gave is just misleading.
What is written there is about limiting masses of low-quality bug reports and feature requests,
which does make sense but is not applicable at all to the severe issue I brought up here.

[DDvO]

A general remark.
Bugs, including security flaws, do not get fixed by regarding reported issues as feature requests,
force-stopping their discussion, and then closing the reports, which boils down to willingly ignoring them,
as done by @scottnonnenberg (or @signalapp, respectively) and bots like @automated-signal on #1895 and #2008.

[DDvO]

And please do not repeat the excuse given by @scottnonnenberg back in 2017
in #1895 (comment) and by @Dyras in 2018 in #2008 (comment) that
(not) handling this flaw is a matter of priorities and the team is too busy with other stuff.
Fixing this security leak should have high priority, and should not really be hard to do,
in particular since there is already a placebo encryption for the message database.

Until this is fixed, the workaround is clear:
Do not use Signal (at least, not the desktop client) for exchanging critical data.
There are other instant messengers that take security more serious, such as Threema.

[DDvO]

A worrying issue here is that even if you do not use the Signal desktop app yourself,
folks you communicate with may use it, likely without being aware of this issue and without you knowing.
I was not able to find any caveat on this issue, neither on signal.org nor in security reviews.
The whole issue does not shed good light on Signal's attitude to protect their users' data.

[hiqua]

It's about processes. Leaving this issue open or closing it does nothing to implement this feature, nor does it impact their priorities. They already know it's not there anyway, so it's not helping. It does however make it harder to see which bugs are actionable, since it's essentially noise. But #5541 already explains that.

[DDvO]

This bug is actionable, but apparently nothing has been done about it since 4+ years.
Another actionable thing would have been to warn users not to use Signal for anything critical until the leak is fixed.

[DDvO]

There would be more detail to mention here w.r.t. technology and effects of this bug,
but in terms of responsible disclosure I'm not going to do that for the next two weeks,
giving Signal security staff time to react (be it publicly and/or in a 1:1 exchange).

[hiqua]

That'll be my last comment here, so last try: imagine if you hadn't created this issue. What would be the difference? Given that:

• they're fully aware this is not implemented,
• there's nothing in your comments they don't know,
• they don't prioritize features depending on random GH issues (and let's hope it stays this way) and it's probably on their roadmap already anyway,

my point (and what #5541 tries to convey) is that there would be no difference, apart from the noise it adds.

If you're really interested in getting more impact here, you'd be better off convincing users on the forum.

[DDvO]

Thanks @hiqua for your further comments.

Ah, so far I had not paid attention to https://community.signalusers.org/
but I just had a look and noticed that there are many related entries, such as

• https://community.signalusers.org/t/password-protect-signal-desktop/1067
• https://community.signalusers.org/t/lock-the-desktop-app-with-a-password/1383
• https://community.signalusers.org/t/improve-security-of-desktop-apps-encryption-of-data-at-rest/26494/6
• https://community.signalusers.org/t/storage-of-the-message-history/31882/3

I am not so much a Signal user, but a security professional currently investigating into messenger security.
I am used to the OpenSSL issue tracker, and this is where (most of of) the actual technical exchange happens.
The Signal users forum naturally is - on average - not very deep into (crypto etc.) technology.
What should it help if I convince the crowds there that there is a severe security leak,
apart from deterring them from using Signal any longer in case they really want/need security?

And I find it even more weird to learn that until early 2018, Signal on Android supported sensible protection,
namely let the user to provide a master passphrase used in the encryption of local storage,
but by Signal-Android commit f36b296e2 of Jan 2018, which became part of version 4.16, this was removed!

From a security standpoint it is depressing to read that Signal was pledged not to do this, but still did:
https://whispersystems.discoursehosting.net/t/passphrase-encryption-only-for-message-contents/917/3

[DDvO]

All right, I've entered the discussion on this and related topics on https://community.signalusers.org/,
in particular Signal and Encryption at rest.

[mennucc]

If you want more security, then you may use a tool that encrypts the filesystem (such as LUKS in Linux): this will hamper access to all your personal data, if the PC/notebook is stolen. This also is more convenient than having encryption keys for each and any program managing sensitive data; indeed you can have a master password in Thunderbird , and you can encrypt documents in LibreOffice, but then in the end encrypting the whole filesystem makes more sense, IMHO.

[DDvO]

Thanks for your response - I agree that FDE is more convenient to use,
yet as I wrote in #5703 (comment), (for various reasons) most Linux systems are not installed with disk (or partition) encryption,
and this does not protect against spyware running on the system.

[mennucc]

If you are using EXT4, there is provision for encrypting a directory tree, even when it was already filed with data. For BTRFS it is still work in progress. As for protection to spyware... when it is running in the system, there is not much you can do, it could keylog you access to Signal and use the password you insert to read the databases anyway.

[DDvO]

All the system-level protection options strongly depends on the capabilities of the owner/user of the system, which in most case are not sufficient.

Concerning spyware, it depends on its capabilities. A pretty targeted one would need to be installed and need to interact with the running app in order to recover or work around the encryption.

[DDvO]

As discussed at various places here and on the user forum, there are various reasons why a user may feel the need to have the (possibly extra) level of protection by a user-defined passphrase.

I see no good reason not to offer additional encryption based on a passphrase (optionally) provided by the user, in particular since the ingredients are readily available, even a PR: #5465 that implements this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to inactivity.

[ksaadDE]

• random

quote of the comment by @hiqua

It's not random, it is contentious wish by the majority of the community of Signal - even in the Forums.

I am still wondering why you try to fight against a useful and proper feature? What are your fears?

@DDvO #push

[ksaadDE]

[...] when it is running in the system, there is not much you can do, it could keylog [...]

You can mitigate keylogging^^ Depends on the access and the other mitigations of the system.

However, where is a plausible, proper argument against the additional protection? Since:

• a) the feature is/was requested by the community over and over
• b) it is a useful and proper feature
• c) the work is already done

[DDvO]

This issue was closed automatically after three months of 'inactivity' and after a pretty short warning period of one week.
Even I as the reporter am not allowed to reopen it.

This is bad style.
Issues are not solved by neglecting them.

[DDvO]

The ultimate conclusion from this topic, which is discussed also in many other places is:

Signal does not really care about its users.

[ksaadDE]

Signal does not really care about its users.

At least not about the people who contribute (either in Community or as devs)... ^^

[ksaadDE]

This issue was closed automatically after three months of 'inactivity' and after a pretty short warning period of one week. Even I as the reporter am not allowed to reopen it.

This is bad style. Issues are not solved by neglecting them.

Why issues in their opinion there is no issue xD They argue with "this is not a security issue, because you could have keyloggers" lmao

[DDvO]

Signal does not really care about its users.

At least not about the people who contribute (either in Community or as devs)... ^^

Right. Those in rule/responsibility of Signal even keep others from contributing what is wanted/needed by users concerned about security.

[ksaadDE]

Signal does not really care about its users.

At least not about the people who contribute (either in Community or as devs)... ^^

Right. Those in rule/responsibility of Signal even keep others from contributing what is wanted/needed by users concerned about security.

People might wonder, WHY. We should send it to an news paper, which reports about tech conflicts.