Security holes : messages not deleted in the database and the server

[link2xt]

@bob789

1- When deleting a conversation, the messages still remain on the mail server (test carried out on an Android phone and a Windows desktop). On the two mailboxes (mailo.com server for both) the messages are not deleted on the server.

This is by design, deleting a chats deletes messages locally, not remotely. Deleting individual messages schedules a job to delete them remotely too. I am not sure right now why this is the case, but changing it will probably cause problems with users using another client side-by-side with DC and having all messages to a particular user deleted is probably not expected when you delete a conversation with a contact.

Edit: also note that in multi-device setup the conversation will not be deleted from your other device. And your server (most likely Dovecot) will by no means securely delete the messages, it will do it in the fastest way possible.

@bob789

2- When deleting a conversation in Delta Chat Android or Delta Chat Windows, the messages are marked as deleted in the database (qb.sqlite on windows) but a simple hexadecimal search shows that they are still in the database . They can be recovered. The PRAGMA secure delete direction is not even enabled in the code.

PRAGMA secure_delete=on is enabled here:

deltachat/deltachat-core-rust/blob/d8ba466c6a2154b54adc5fd7688644432c70f773/src/sql.rs#L87

If it does not work for some reason it is a bug indeed. I have just checked my account database with a command-line tool and it says secure_delete PRAGMA is enabled.

$ sqlite3 ac0/db.sqlite 'pragma secure_delete'
1

Note that messages are stored in “blobs” outside the database, so secure_delete is not protecting outgoing message contents from being persisted to disk (if they are encrypted, they are stored in encrypted form though), and may not even protect the database for some filesystems. The only bulletproof solution I see is to always use full disk encryption provided by your operating system.

Edit: even the page you linked to says the same: “Be aware that SQLite cannot securely delete information from the underlying storage device. If the write operation causes the filesystem to allocate a new device-level block, the old data may still exist on the raw device.”. Storage encryption is better done at the operating system level.

@bob789

In addition, the VACUUM sqlite command to purge the database is not even executed when launching the Windows or Android application.

VACUUM is executed periodically during “housekeeping” job.

@bob789

3- The database on the phone or Desktop is not even encrypted with a user password and the option does not exist.
If someone has access to the phone or the computer they can retrieve all the messages.
In addition, the password for the mailboxes is written in clear in the database.
The thief will therefore no longer have access to the entire email box.
It really sucks as a security!

See related feature request about local encryption:

Local encryption

Please, implement encryption of attachments and text messages while they are stored locally on the device. Apps with root access can read unencrypted text and see attachments. For instance, look how it is done in Signal and may be Threema (which is not open source). Is it possible?

Encrypting the database makes some sense if you store everything in the database and want to have encrypted backups, you can simply re-encrypt the key with a new passphrase and copy the rest of the database. But it does not make the data on device more secure unless you keep asking the user for passphrase each time and user actually uses secure passphrase. It’s not really usable, this is why I think it’s not available in Signal, but only in Signal fork Molly. So I think we should encourage users to use filesystem-level encryption rather than trying to implement local encryption into the core.