Force setting passphrase when enabling automatic backup

[Lord-KA]

I wanted to update simplex to 4.5.2, that hasn't been released to fdroid yet. I preemptively enabled backup using seedvault (LOS 20, android 13), it backed up files, and only then I set my own db passpword and exported it manually. When I installed github version, it couldn't find the db in the backup (android treats them as different apps, thats ok), but when I reinstalled fdroid version, it found backup and couldn't decrypt it automatically nor with my set password. It seems that auto backup is encrypted with random password unknown to user. Common sence behavior would be having db unencrypted (as seedvault provides its own backup encryption) or at least ask user for password before enabling auto backup.

Steps to reproduce: 1) don't set your own backup password 2) enable backup 3) restore this backup after reinstall 4) face "wrong database passphrase" screen with no right answer 5) loose whole profile

[epoberezkin]

Agreed, thank you, it’s already in todo list.

we plan to require user-provided passphrase before backup can be enabled in the app.

[epoberezkin]

I don’t like the idea of having database unencrypted because 1) most backup solutions are not encrypted 2) there are various other attack vectors on app storage. Random passphrase is a better trade off, but you are right that backup should be disabled in this case.

[Lord-KA]

Personally, I see ability to read filesystem by an attacker as a Game Over TM, but there is no harm in another encryption layer as long as usability is not being hurt.

[epoberezkin]

Not necessarily game over. Attacker may be able to read files when they have a physical access to the device, but encryption adds the layer of protection that the attacker may be unable to break. It's called "defence in depth" in security – multiple layers compensation for deficiencies.

[RageGamerBoi]

I don’t like the idea of having database unencrypted

From what I understand this to mean, the local database is unencrypted. If that’s the case, well… A locally unencrypted database is a really bad idea for so many reasons… Especially because the only thing between an attacker and your data is you accidentally typing your phone’s password in public. https://appleinsider.com/articles/23/02/24/if-both-your-iphone-and-passcode-get-stolen-youre-in-deep-trouble There NEEDS to be more security. Briar did it, way can’t this? This is the MOST important thing to fix with SimpleX, give it top priority, this is really bad.

And even if it is encrypted, it clearly doesn’t require a password to access the app, so there’s something wrong here…

[epoberezkin]

From what I understand this to mean, the local database is unencrypted.

You misunderstood. It's always encrypted, but initially with a random passphrase that is stored securely with KeyStore (using TPM if available). The problem is that the app allows enabling backup without changing it to manually chosen passphrase, and as a result this backup is unusable, because if you remove the app, you lose this random passphrase.

[Lord-KA]

And even if it is encrypted, it clearly doesn’t require a password to access the app, so there’s something wrong here…

This is a little bit off topic, but I don't think that another symmetrical encryption layer solves something. Most of the devices are not secure anyway. None of the laptops I know support AEM/SecureBoot that hasn't been publicly broken at least a few times. With phones it is a little bit better, but not great either. On the other hand, if you want to implement some kind of 2fa, it would be fun (e.g. yubikey NFC-based u2f signing to access the db).

[epoberezkin]

done in #1962

[epoberezkin]

And even if it is encrypted, it clearly doesn’t require a password to access the app, so there’s something wrong here…

I could never understand a threat model when a separate PIN to access the app adds any protection, so being puzzled by seeing this separate PIN in Signal and some other app we did what is much better - biometric level protection to open the app. But we've discovered that a lot of people believe that having a separate PIN somehow improves their privacy, and there are some narrow scenarios when they believe they cannot refuse to open the phone but can avoid opening the app (not sure why). Also, there is a legal difference in some jurisdictions when refusing to provide device PIN can be seen as a criminal offence (because it's equivalent to refusing to decrypt data - there was some case in French high court about it), but refusing to provide app PIN that simply provides access will be ok...

Personally, I don't buy any of these arguments, and would always prefer using device biometrics to access the app over app-level PIN. For any scenarios requiring high security I would use database passphrase that is not stored on the device.

But because having a separate app PIN is a VERY popular request from the users, we will cave in and provide it, to cater for these narrow use cases where it may be justified and to make people "feel" more secure. My strong recommendation will be to use biometrics or biometrics + off-device-passphrase, and not PIN. But, as I said, PIN will be available.

[epoberezkin]

To clarify, by "biometrics" I really mean any device-level authentication you are using - the app delegates to OS to authorise the access in this case, it has no access to any password, PIN or biometrics you may use to access the device - both iOS and Android provide APIs to use it from within the app.

[epoberezkin]

Using a single hard-to-guess passphrase to access everything (device and all apps) is usually considered as more secure than having many easy-to-guess different PINs, it is the same logic that justifies using password managers with complex random passwords hidden behind a single hard-to-guess-easy-to-memorize passphrase.

[RageGamerBoi]

You misunderstood. It's always encrypted, but initially with a random passphrase that is stored securely with KeyStore (using TPM if available). The problem is that the app allows enabling backup without changing it to manually chosen passphrase, and as a result this backup is unusable, because if you remove the app, you lose this random passphrase.

Ah, alright

This is a little bit off topic, but I don't think that another symmetrical encryption layer solves something. Most of the devices are not secure anyway. None of the laptops I know support AEM/SecureBoot that hasn't been publicly broken at least a few times. With phones it is a little bit better, but not great either. On the other hand, if you want to implement some kind of 2fa, it would be fun (e.g. yubikey NFC-based u2f signing to access the db).

That’s fair, and it would only work before the database is unlocked, but it’s good if the device is physically taken and your phones pw is compromised (because it basically is). Panic Buttons could use the feature too. An encryption layer for different reasons.

Using a single hard-to-guess passphrase to access everything (device and all apps) is usually considered as more secure than having many easy-to-guess different PINs, it is the same logic that justifies using password managers with complex random passwords hidden behind a single hard-to-guess-easy-to-memorize passphrase.

A PIN is a terrible idea ofc. I’m talking about a system similar to KeePassXC’s login process but instead of all your passwords, it’s your sensitive chat data. The threat model that requires this is a really strict one, but there are definitely some people using SimpleX for that purpose. Now that I understand what SimpleX is actually doing, it makes more sense, but it would be a good optional feature for those that need everything you’ve got.

[epoberezkin]

Right, can you please describe how you see this feature?

[RageGamerBoi]

Like how it would be implemented or used? I described the use-cases I could think of (there are probably a few more) in my previous reply. As to how it would work, think something similar to this: