I would caution against this approach. This fundamentally changes the 2FA from a "something you have" to "something you know", which is the type of factor your password is. If you do want 2FA functionality on the command line, look into Yubikeys with their ykman CLI tool. (https://support.yubico.com/support/solutions/articles/150000...) You're able to store a TOTP secret on the Yubikey itself (maintaining it as a "something you have" factor), as well as optionally requiring the yubikey be touched before the TOTP is emitted.
I 100% agree with you, but I recently started putting my TOTP tokens in my password manager, and it's so much more convenient to just have the token pasted in while you log in, instead of having to find the phone, turn it on, launch the 2FA app, find the code from a huge list and type it in, that I'm willing to take the security hit.
Agreed, I hesitated for years to not put 2FA in 1password. But, after a few phone upgrades and resetting each and every account, it's worth it. It can take nearly 10 minutes per account to reset 2FA. Spending a few hours every few years doing that was just too much.
Putting your 2FA in 1Password sort of reduces your security back to 1 compromise (breach 1Password and you're screwed). I would recommend putting your TOTPs in Authy. Easy to restore and even in multi-device mode waaaay safer than storing all your TOTP next to your passwords.
You just give Authy a relatively simple password, and don't save it anywhere. If you don't have Authy in multi-device mode it will be impossible to activate another session, and if you do activate another session while in multi-device mode Authy will check if any other devices are active and if so will ping those devices with a verification request. It checks for an active device so that if you have only one device active and do a reinstall you can still activate.
I have my 2FA backup codes in Dropbox, which itself is behind 2FA.
In essence someone has to both get my 1Password password, 1Password secret key and either compromise my phone (for Authy) or my phone number (to recover 2FA backup codes via Dropbox SMS recovery), or my computer (for direct Dropbox access). But very few organisations have that amount of capability and I have nothing stored in my accounts that is worth that capability. If I had, I would store it behind GPG and a password that is only in my mind.
Also, to lose access I'd need to lose my 1Password secret key or forget Authy password + get logged out of all my Dropbox devices simultaneously. The chances of that are rather slim.
I take the secret from the initial signup (2d-barcode/hex string) and encrypt it with my public keys (private keys are on 2 different Yubikeys) and then distribute them to 3 different computers. Overkill, especially given that encrypted local iPhone backups store the GoogleAuthenticator secrets, but it means I won't lose my 2FA secrets if I lose my phone.
Store your TOTP secrets PGP or NaCL encrypted. I have done this for years. You'd have to get my private key (off of a smartcard) and get my private key password (out of my head) to decrypt my TOTP secrets before you could use my TOTP generated codes. I have much more faith in this approach than I do Android apps.
Or have the ability to run code on your computer, in which case they’d just wait until you enter the private key password and then steal all your TOTP secrets.
Having your TOTP secrets on a unique device means that an attacker in that scenario (access to your endpoint) could steal a single TOTP code for the single site, but wouldn’t be able to steal the seed secret itself.
Yup. It's arguable whether TOTP secrets stored in Google Authenticator are a true "something you have" factor, but this came at a tradeoff because not everybody wants to pay for a RSA token generator and carry that around. Assuming the Android system is secure (big assumption, bear with me here), this is closer to a "something you have" factor because its difficult, if not impossible for users to retrieve the secrets from the GA app.
TOTP as a "something you have" approach to 2FA is entirely dependent on how well the device secures the secrets.
An RSA key's private key is (nearly?) impossible to retrieve. The Google Authenticator's TOTP keys are a bit easier. A file on a laptop is even easier.
I believe iPhones now come with on-board TPM's? So in theory you could actually generate the private key on the TPM, and then your phone becomes the "thing you have" to a higher degree of security than authenticator apps.
Not sure about any apps that take advantage of that yet, but the hardware seems to be there.
TPMs have been in phones for years actually, both iPhones and Android phones. The iPhone chips have become a lot better the last year or two though. Some apps, like government or banking apps, actually have been using ARM TrustZone (and probably Apple's T2 chip) for secret storage already.
If you use krypt.co, you can store ssh and GPG keys on your phone's TPM, as well as a secret key for use with a browser addon to facilitate WebAuthn. So, you can already use your phone as the "thing you have".
Well, Android devices do have "Trustzone"s, where keys are bound to the hardware, and user's identification (pin/password)
Sadly, Google Authenticator doesn't seem to be using that.
AndOTP does have Android KeyStore backend, which is using Trustzone.
I think 2FA objective is to protect mainly from password leaks. If an attacker has access to the files on your laptop aren't they able to intercept 2FA codes too even if they are generated on another device? Such attacks are not purely theoretical we could observe them in real world.
Apart from that I believe that TOTP keys should be encrypted and that is actually my main issue with the described tool - it stores the keys in plain, in a config file.
2FA is to mitigate risk after the password is compromised, not to prevent password compromise in the first place.
That doesn't change the necessity of protecting TOTP keys, session keys, bearer tokens, etc., it's just that your second factor is supposed to be a parallel factor, not an extra lock around your password.
For my threat model (and I suspect for most people's), access to copy files on my laptop implies access to install active malware on my browser sessions, i.e., it's already game over. If you don't have that access, then a file on my laptop is in fact something I have.
(I have a few things I intend to be survivable across a total laptop compromise, but they're special-case things like credentials that can upload code that will be run by a few thousand people. They're not protected by regular website 2FA. For regular websites, a browser compromise would almost always let you wait until I'm logged in, then disable 2FA and change both the email address and password on the account, at which point it's irrecoverable.)
Indeed. Doing this with the OS TPM or secure enclave might have been worthwhile, but without that it's basically a fancy way of writing a password on a post it.
Depending on how the original OTP key is stored on your phone, it's not much better than having it on your laptop. The key is still just stored there, somewhere, inside our phone. On the laptop at least you know where and how it's stored.
This might seem intuitive but it's wrong unless your phone is really old and unpatched. Modern phones sandbox everything, often encrypted per-application (standard on iOS for many years, becoming common on Android), and they have storage classes which will not be included in backups or easily copied to a computer.
You could start to approach that on a laptop — make sure you have FDE enabled, use the operating system's sandboxing features pervasively, store secrets using the TPM, etc. but that's a huge amount of work and the attack surface for apps on your laptop is enormous, especially for developers: how many people using a system like the one described are one unlucky npm install away from sending their TOTP seed to an attacker? The equivalent attack requires a system compromise on a phone (which tend to have 7+ figure USD bounties on iOS).
The rate of CVEs an android, combined with the sheer number of manufacturers who are slow about updates or just never deliver any, means that unpatched devices are nothing like the rarity that this statement suggests.
We do know how and where it is stored, a database file in /data/data/com.google.android.apps.authenticator2/databases/databases. I regularly copy it and back up in case my phone needs resetting.
This is just assuming that your phone is more secure than your laptop. Which is possibly the case but files on a phone are still copyable the same way files on a laptop are.
