Recreate backup transfer device message for a week after backup transfer ends

[link2xt]

On backup transfer, config option should be written with a timestamp of the last backup transfer. For a week after backup transfer, the message created in #4301 should be recreated to prevent its deletion.

This does not protect against direct database modification, but if attacker can modify the database, they can as well copy the database with their own tools that bypass any protections.

To protect against rewinding time back before doing backup transfer, timestamp should be checked not to be in the past compared to the previous backup, the last received message and other similar timestamps.

[r10s]

On backup transfer, config option should be written with a timestamp of the last backup transfer.

maybe we should write the config option already when transfer has started, so that one cannot abort backup at 90%.

that could also be used to differ between successful and failed transfer, even when the app crashes in between.

To protect against rewinding time back before doing backup transfer, timestamp should be checked not to be in the past compared to the previous backup, the last received message and other similar timestamps.

at least on macos, you need the system credentials to modify the time. +1 for additional plausibility checks, however

[iequidoo]

For a week after backup transfer, the message created in #4301 should be recreated to prevent its deletion.

Deletion of the message by the user? If we can't protect from attackers having access to the db, who else can delete it?

[link2xt]

Deletion of the message by the user?

Yes, the purpose is to notify user if someone has access to the device for 5 minutes, enough to copy do second device setup but not to disassemble the device, copy the database etc.

[iequidoo]

The device chat can also be archived, notifications muted, so the user may miss the backup transfer message.

EDIT: The first measure should be asking for the user's system password / screen lock before showing a backup QR code, which is already done on Android, but i'm not sure if/how that should be done on Desktop.

EDIT: Another question -- when to recreate the backup transfer message? E.g. an attacker may read it, but not delete, so again, the user may miss it. But if we recreate it even if it already exists, it will annoy users.

[r10s]

The first measure should be asking for the user's system password / screen lock before showing a backup QR code, which is already done on Android, but i'm not sure if/how that should be done on Desktop.

note sure as well for desktop, but that is another issue :)

EDIT: deltachat-ios meanwhile also asks for "device owner verification"

E.g. an attacker may read it, but not delete

then, there are good chances, the user will notice - the device-message chat is sorted quite up, and it is also not that rare that the user enters the archive, if they are using it. if the user was not using the archive before, even more, as there is suddenly an "archive" button.

when to recreate the backup transfer message?

keep it simple to move forward: just re-add the message after a week when it was deleted before.

the if-not-deleted should be good enough to not annoy or surprise users

as said, even in archive, the user has a chance to notice it (usually, user enter archive from time to time - and on re-adding there is even a badge in case the device chat is archived+muted).
an important thing about all that effort is also that the attacker cannot be sure not to get get caught. in another iteration, we can consider to un-archive or so, but i would not do that initially to move forward.

it is all not 100% but "best effort". doing sth. is an improvement, we can always iterate.

[dev24126]

On Windows desctop you can check Windows Hello, e.g. for using the System Login PIN. This can also be used by an App through the Windows Hello-APIs.
https://www.microsoft.com/en-us/windows/tips/windows-hello#:~:text=Ja%2C%20eine%20Windows%20Hello-PIN,Buchstaben%2C%20Zahlen%20und%20Sonderzeichen%20enthalten.

https://learn.microsoft.com/en-us/windows/apps/develop/security/windows-hello-auth-service

[r10s]

to sum up actionable items to close this issue:

• check, that on backup-start, the time is not in the past. checking the newest timestamp from msgs table seems good enough (that is compared against other means to not be in the past on receiving). if we consider it being the in past, emit an error and do not backup (the error is shown to the UI as usual)
• on backup transfer, remember the time of the transfer and the message-id of the device-message added
• after 7*24 hours, check if the device-message was not deleted (so, is still visible to the user, even if archived or marked as seen)
• if it was deleted, recreate the device message as done originally (no other special handling needed)

the 7*24 hours do not need to be exact, next housekeeping eg. is fine.

for a follow-up, not needed to be solved to close this issue: question is what to do with multiple transfers, so if Evil does a transfer and within the 7 days, the user does another one. as it is anyway not about being 100%, we could to ignore that situation, or emit the message directly before the new backup (it is anyway only emitted if it was deleted before) (remembering N backups seems over-engineered)

[iequidoo]

or emit the message directly before the new backup (it is anyway only emitted if it was deleted before)

+1