James Thew - Fotolia
How did Signal Desktop expose plaintext passwords?
The Signal Desktop application was found to be making decryption keys available in plaintext. Learn how the SQLite database and plaintext passwords were put at risk.
Researchers discovered Open Whisper Systems' private messaging application Signal Desktop makes decryption keys available in plaintext. What kind of risk does this pose for users? Should security teams scan systems for exposed plaintext passwords like this?
Signal Desktop uses a SQLite database to store user messages, but the way the application encrypts those locally stored messages can expose decryption keys that are stored in plaintext.
The Signal Desktop application automatically generates encryption keys for the databases it uses, but the encryption key used to protect the database of encryption keys is, itself, stored in plaintext. This makes it possible for an attacker to easily gain access to encrypted messages without authentication as long as the attacker has local access to the system.
While this exposes data at rest on the system, Signal has stated that it never intended to provide encryption at rest and that users can use full disk encryption if they want to protect data at rest on their systems.
Each time the Signal Desktop application opens the database, it stores the encryption key in plaintext to a local configuration file. For a PC, the file is:
For a Mac, it is:
To begin the attack, an attacker can use a SQL Database Browser program to open the database here:
The attacker is then prompted to enter an encryption key.
An attacker with local access to the system could access the encryption key from the config.json file. In addition to Windows and Mac, the program can also be downloaded on Linux, Fedora, Debian, Ubuntu and FreeBSD devices.
Signal recommends using full disk encryption to mitigate this type of attack. Security teams can also scan systems -- particularly local configuration files -- for exposed plaintext passwords and encrypt the files. Likewise, users should be required to enter a password to generate an encryption key that is never stored locally.
Other ways to prevent inadvertent exposure of plaintext passwords include:
- physically securing encryption keys with locked doors with proper user access controls;
- storing encryption keys and the data they are used to unlock on separate machines;
- using audit logs to show who has accessed encryption keys and when;
- using multifactor authentication in an addition to passwords;
- encrypting configuration files and assigning a file extension that NotePad can't open;
- encrypting encryption keys as another security layer; and,
- backing up encryption keys off site.
Ask the expert:
Want to ask Judith Myerson a question about security? Submit your question now via email. (All questions are anonymous.)
Dig Deeper on Identity and access management
Related Q&A from Judith Myerson
Site-to-site VPN security benefits and potential risks
Not every enterprise needs the functionality of a standard VPN client. A site-to-site VPN may be a better choice for some companies, but it's not ... Continue Reading
Should I worry about the Constrained Application Protocol?
The Constrained Application Protocol underpins IoT networks. But the protocol could allow a threat actor to launch an attack. Continue Reading
How can I protect my self-encrypting drives?
Dutch researchers discovered flaws in ATA security and TCG Opal affecting self-encrypting drives. What steps can you take to guard data stored on ... Continue Reading