Data should be encrypted about freeotp-android HOT 12 CLOSED

The Guardian Project offer libraries that would hopefully make implementing encryption easy.

See SQLCipher and IOCipher here https://guardianproject.info/code/

from freeotp-android.

Responsible for deploying university-wide two-factor authentication I have two recommendations here (just providing my personal perspective, which is in line with most of the colleagues I talked to ;-):

• I very much like the plan for implementing the encryption of secrets in FreeOTP. Me and my colleagues already had a look at it a year ago and missed it. At the moment we recommend Google Authenticator for TOTP/HOTP tokens, but an open source alternative with encryption enabled and the backing of a big organization would be favorable.
• On the other side, as I see a token as something related to the device (and not to a backup/synchronisation cloud), I dislike the idea of backing up user credentials (like username, password or token) in cloud systems, because it opens additional vectors for attackers and does IMHO not comply with most data security and privacy rules of state organisations (or possibly big companies, too). The usual way of moving to a new device should be to use the new phone and to roll out a new token (either using the old token's otp in a self service portal or contacting the organisation's service desk).

from freeotp-android.

Modified by simo on 12 Dec 2013 16:23 UTC

from freeotp-android.

Modified by npmccallum on 10 Jan 2014 22:01 UTC

from freeotp-android.

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.

from freeotp-android.

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

from freeotp-android.

Modified by dbrgn on 20 Jan 2016 22:53 UTC

from freeotp-android.

Modified by woi on 17 Jul 2016 19:42 UTC

from freeotp-android.

Disabling backups would, well, limit the ability of the legitimate owner of the device to backup the database. Requiring the database to be unlocked (i.e. decrypt the database, preferably something standard like AES-256 + PBKDF2 or scrypt for key stretching) would enable it to be backed up, while also retaining the security for the backup. This would be similar to how KeePass behaves.

from freeotp-android.

Basically, my plan is to require the Android KeyStore for this. Keys would be locked to the device with no backup capabilities. This would match the features on the iOS branch.

Currently, we have too many users on older Android to enforce this as a requirement. I'd be highly motivated if we could drop support for older versions of Android. But as it stands, this feature would need to be optional.

Patches for this feature are welcome. Otherwise, hopefully I'll get around to it.

from freeotp-android.

Having to regenerate dozens of OTP logins is very difficult. In fact, it might be near impossible if you've happen to lose the codes, that only some providers give you, for when the device is offline.

It would be nice to be able to export (through the app, not the android backup) an encrypted version of the database, similar to what is done with KeePass.

from freeotp-android.

Actually because GoogleAuthenticator cannot backup codes I'm looking for something else, so I guess disabling backups isn't the best option, unless there is no other way to backup all of them.

However, the thing about rooted devices, well... if your device is rooted and you got malware or you got infected by a malware which root your device, then you are doomed anyway. No matter you encrypt it or not. In all cases you still need to store the encryption key somewhere and it doesn't matter if it's in priv shared prefs or in the keystore. A malicious app running as root will be still able to get the data. When an app has root access it's just a matter of writing the right code to instrument your app to sniff keys to decrypt the data.

So I also thing it'd make sense to implement some backup/restore feature, encrypted of course and then you can safely disable backup in the manifest.

from freeotp-android.