Data should be encrypted

[npmccallum]

Reported by simo on 12 Dec 2013 16:21 UTC Application data can be accessed on rooted devices or by getting access to backups (esp. on the cloud), it should be possible (and actually encouraged by a setup wizard on app. startup) to encrypt the data store, and decrypt it at application statrup via password/pin/gesture/biometrics/whatever :)

[npmccallum]

Modified by simo on 12 Dec 2013 16:23 UTC

[npmccallum]

Modified by npmccallum on 10 Jan 2014 22:01 UTC

[npmccallum]

Comment by jpl on 4 Sep 2014 07:32 UTC As an extension to this theme, I think there could be an option to flag the database (android:allowBackup) to prevent backups. If someone borrowed my phone, they could backup the database and extract the secrets. By simply marking the database in this way, the phone prevents backups and closes this attack vector. I don't know if this can be done after install-time, as it seem to need to be set in the manifest, and I'm not Android programmer. Perhaps there's another way to block/regulate backups in an application that doesn't need the manifest setting.

The android developer guide states: "Caution: Because the cloud storage and transport service can differ from device to device, Android makes no guarantees about the security of your data while using backup. You should always be cautious about using backup to store sensitive data, such as usernames and passwords."

The Google Authenticator app disables backups. This may give it the edge on corporate phones such as the Samsung devices that have Knox.

I'd be happy with options that allowed enabling/disable backups and encryption/password also. The database could be encrypted always, regardless of whether backups are enabled, so that phones that are rooted are not vulnerable, and backups that are compromised are not vulnerable. The default encryption could be tied to the phone UUID, but there could be an option to set a PIN/password that seeds the encryption, and must be entered to unlock the database.

Encrypting with a device UUID would essentially any export/import feature. Also, if I replaced a broken phone, the restore would not be useable on the new device. So perhaps that could be an option: "Prevent backups from being used on other devices". However, if you had an explicit import/export, the database could be re-encrypted without the UUID for this special case, and maybe the exported file can be sent to a "share" intent, to be sent via email/bluetooth/pushbullet to the new device.

Actually, what would be neat here is for the export function to require entry of the UUID of the device that will import the database, so that the exported blob cannot be captured and used by an attacker. This would probably be best done using a key-pair generated by FreeOTP on the new device, and the public key displayed as a QR code for FreeOTP on the old device to use.

[npmccallum]

Comment by dbrgn on 20 Jan 2016 22:52 UTC Unlocking with a PIN or a gesture would be great. Authy does it too.

[npmccallum]

Modified by dbrgn on 20 Jan 2016 22:53 UTC

[npmccallum]

Modified by woi on 17 Jul 2016 19:42 UTC

[kennwhite]

It might be worth looking at SecureEnclaveCrypto by Trail of Bits. This could address the snatch-and-grab threat scenario where the device is unlocked, and a thief now has access to all your 2FA codes as well. Adding TouchID or some kind of SE PIN would be a great enhancement. Thanks again @npmccallum.