[lrvick]

For AWS you can use your yubikey indirectly for now via "Yubico Desktop" or "Yubico Authenticator" which emulate TOTP mode.

You can then go through the "Virtual MFA" flow in AWS and keep the TOTP secret inside the yubikey with a touch requirement.

This is nowhere near as ideal as U2F but it is a huge step above Google Authenticator which stores all secrets in plaintext in an sqlite database.

Also the 2FA support of 1password is entirely cosmetic if an attacker has malware on your machine. It decrypts your entire database against one secret.

I would encourage consideration of solutions that only decrypt the credential being reqested that don't expose the decryption key to the system: https://github.com/lrvick/security-token-docs/blob/master/Us...

[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-...

[arianvanp]

Yes Yubico Authenticator is super useful! Though... The QR Code scan option does not work on Wayland, and you can also not manually paste the secret in Wayland.. You need to manually type it in which is a PITA. Luckily there is also a commandline version of the tool:

    ykman oath add

[dagheyman]

Hello, Yubico Authenticator maintainer here. Please file a github issue for the Wayland problem and we'll see what we can do. https://github.com/Yubico/yubioath-desktop

[arianvanp]

Yes, will do :) I'm afraid the QR code one is gonna be tricky, because of the way Wayland works. but the C/P issue is probably something with Qt + GTK3 that are confusing eachother