[stcredzero]

is a huge step above Google Authenticator which stores all secrets in plaintext in an sqlite database.

...I'm beginning to feel angry again! WTF Google? Why isn't Google Authenticator using an encrypted store with the keys stored in the iOS enclave?

[akerl_]

This makes it sound like the secrets are just printed out and posted on a notice board somewhere, which is pretty much straight fearmongering.

The sandboxing between apps on non-jailbroken iOS (and to a lesser extent un-rooted Android) is such that having the secrets stored in an app's database renders them secure against basically any attack that doesn't involve physical access to the device.

Given that the app needs access to the symmetric TOTP keys for it to work, most of the available other options aren't appreciably changing the security model. Encrypt the DB with a magic secure-enclave-stored key? Now the app is just asking to decrypt the DB every time it's opened. What attack are you worried about where this new setup isn't equally vulnerable?

[fanzhang]

If someone gets a hold of your lost phone, without the secure enclave, rooting it is easy with physical possession. Whereas with a secure enclave, physical access with a locked device doesn't give the secret away.

[chimeracoder]

> If someone gets a hold of your lost phone, without the secure enclave, rooting it is easy with physical possession.

Rooting an arbitrary Android phone is not easy, and rooting an arbitrary Android phone (especially the Nexus/Pixel flagship devices) without wiping the storage is really not easy.

[fanzhang]

After looking around, I agree that standard ways of rooting the phone do involve wiping it.

However, it still remains that the secret is sitting in plain text on a hard drive on the phone. If you unplug/unsolder the hard drive, you could just read it, like a PC.

Another advantage is that if the secure enclave is hardware/firmware linked to authentication (fingerprint / password), then there would need to be a vulnerability in that hardware process for a remote users to get a break.

This is the second factor of a 2FA, so I agree that in most cases, it won't be a large issue. Someone who phishes your password over email would empirically be unlikely to hack your phone.

[chimeracoder]

> However, it still remains that the secret is sitting in plain text on a hard drive on the phone. If you unplug/unsolder the hard drive, you could just read it, like a PC.

"In plain text"... on a disk that is fully encrypted. Full-disk encryption has been available in Android for several years, and required for almost all of that time.

[Macha]

Android supports (and at least on my Nexus 5x, enabled by default) disk encryption.

[stcredzero]

The sandboxing between apps on non-jailbroken iOS (and to a lesser extent un-rooted Android) is such that having the secrets stored in an app's database renders them secure against basically any attack that doesn't involve physical access to the device.

It's best not to rely on just one mechanism. Sandboxing mechanisms are also prone to exploits and bugs. For something as important as Two-Factor, Google engineers should be practicing defense in depth.

[tempay]

There is a perk to this method. If the user has a (encrypted) backup of their phone then the backup can be restored to a new phone and keys can be generated. If not replacing a smashed screen would result in the keys being lost, with very little gained in terms of security. I think this is one of the places where added security would risk making the user experience more hostile for little benifit.

(Talking about iOS here, but I’m sure it is similar on Android)

[gruez]

it's not.

cursory search: https://dpron.com/recovering-google-authenticator-keys-from-...