just use ‘pass’ with the pass otp addon, then you don’t have to specify the key on the cli:
pass -c otp sites/somesite.tld
And it keeps your otp secrets (and passwords) gpg-encrypted
As long as you’re going to store your TOTP secrets directly on your machine, this feels way “crappier” than just using KeePassXC or similar. Am I missing something?
It does seem to be missing the point somewhat. TOTP is a protocol for doing crypto with a human in the middle. Putting the human in the middle is there precisely so that the private key can be on a completely different machine to the one that you’re using to log in. The ‘crappy’ authenticator apps (I’ve used the one from F-Droid, which is a fork of the last open-source release of the Google one) manage this for you.
If you’re willing to store the shared secret on the same machine that you use for logging in, then an attacker who compromises that machine can just exfiltrate it directly. If it’s stored in cyphertext on disk (protected by some key) then you’re not vulnerable to offline attacks if someone steals your computer but you are vulnerable to online attacks. If someone compromises your computer then they can read the secret out of memory and impersonate you.
With TOTP and a separate device then they need to do online, live attacks: just exfiltrating the one-time password doesn’t help because it’s stops being valid a few seconds later and they need to log into the remote system in that time window.
You get a small amount of extra security from OTP vs passwords by storing the secret on the same machine. If the attacker is able to compromise your browser then they can leak your password but they can’t leak the secret without a separate sandbox escape that allows them to compromise the credentials manager.
Both are weaker than using WebAuthn. Now that pretty much all desktop and mobile browsers support WebAuthn with platform authenticators, there’s no excuse for using passwords or TOTP. With a TPM, Windows can protect your credentials with biometrics and require a full OS compromise to gain the ability to fake signatures (but not to . Android and iOS / macOS both provide mechanisms. Android will use a separate hardware store if available, a TrustZone-isolated component if not. iOS and macOS will use the Secure Element, on older Macs there’s an emulator that stores credentials in the Keychain, which is much less good for security, but the best you can do on the older hardware. Not sure what the situation is on Linux / *BSD.
There is another angle to this which might be of more practical relevance to most people: on some services, enabling 2FA makes it materially harder for support personnel to reset your credentials. I suspect that the vast majority of people are more likely to have their accounts hacked via social engineering than any sort of credential theft, at least if they’re switched-on enough to avoid installing banking trojans. In that light, enabling 2FA is just a way to opt into something like AAA service you don’t have to be an eight-figure customer for, and it doesn’t really matter how secure your TOTP secret is.
makes it materially harder for support personnel to reset your credentials
makes it materially harder for support personnel to reset your credentials
Yep, ask microsoft about that if they think you’re not using that account often enough. Fun support call times.
I think that really comes down to what exactly you’re trying to secure with TOTP or rather 2FA.
In the original sense: An attacker has to have one more thing than your password and at best more control than only over your PC (with which you’re logging in). Except I don’t trust my phone more than I can throw it and I do use a password manager with long randomized passwords. And I do use a yubikey as 2FA for my password manager. (with this I have probably now leaked everything important about me)
So TOTP to me is mostly a pain that protects me against websites that counter brute force attacks with 2FA*. And it makes those websites shut up about setting up TOTP (let’s be honest: “please enter your phone number”).
And then there is the issue with most people logging into websites also on mobile. So you’re down to one device and the hopes that the per-app isolation of iOS/Android is better than on your PC (which may be true). But that doesn’t help the case that an attacker only requires access to your phone now.
*Except there are backup-codes which are essentially static passwords. Which also highlights the problem of using only your phone for 2FA, I wouldn’t bet on recovering a google account with 2FA after you lost your phone and backup codes - even if you did send them your passport to verify your youtube-over-18-age / bought a lot of stuff with some form of traceable credit card you can verify yourself with. In fact I had to go though multiple hoops because microsoft found my account usage weird and didn’t trust my TOTP to identify myself.
I never understood putting 2FA into your primary password manager.
This makes it a single point of failure. If your password manager is hacked, leaked, or your database is lost/deleted, then you’ve lost everything all at once.
Maybe I’m wrong on this - but I keep my TOTP stuff in a separate app to my password manager (Aegis, in this case). And backup the encrypted keys/database when I add a new TOTP code (which doesn’t happen very often these days).
You’re completely correct here. Some prefer to take the risk in exchange for the convenience.
There is not much convenience in needing to enter a second form, and no added security either, since if your password is already in a password manager, your TOTP code is too.
Well, there is still security against weird unlikely scenarios like “you’ve entered the credentials into a public PC that was keylogged”. (Some would consider the “compromised personal device” scenarios just as unlikely…) And as mentioned in a comment above, recovery policy improvements that happen in some places due to enabling any 2FA. But yeah, TOTP is really unimpressive in terms of what security it can provide.
Sometimes you’re happy with a password but someone else has decided that you have to have 2FA.
I meant to suggest that using oathtool was a “crappier” approach to using TOTP than using KeePassXC or similar. Not that using TOTP altogether was crappy.
Right, and if you think that TOTP altogether is crappy, then it’s just fine to use oathtool :)
Or you could just store your TOTP secrets in your password manager and skip the 3rd party tool entirely. KeePassXC, Bitwarden premium, and many others make this available. Then secure your password manager with a hardware security key. Done
TOTP w/ Bitwarden is nice. It shows up in the same card as the primary authentication method. While user/pass is automated input I have not had success with TOTP autofill but I haven’t looked into it at all.
TOTP doesn’t autofill, that I’m aware of. You have to copy it out of the browser extension and paste it into the field.
The browser extension automagically copies the TOTP for you, at least On My Machine(tm).
I use totp-cli which is still kind of crappy, because I have to enter a password each time I call it. But at least it’s better than finding and getting my phone.
As password manager I use Bitwarden and I remember that they can provide topt too. But I haven’t had the time yet to properly read the docs on that.
The TOTP feature in Bitwarden is really handy for really using
everywhere you can. It will typically fill out username &
the first prompt (on a webpage), and then copy the TOTP to your
clipboard so it’s ready for the TOTP prompt as well.
Just tried it out and indeed it is very easy to setup and use. Thanks for the nudge!
I use my Yubikey with ykman, e.g.
ykman oath accounts code -s bugs.ruby-lang.org
With some basic dmenu wrapper it’s been a perfectly viable solution for me too:
set -o errexit -o nounset -o pipefail
SERVICE=$(ykman oath accounts list | dmenu -i -f -l 16)
CODE=$(ykman oath accounts code --single "$SERVICE")
notify-send Yubikey "$CODE"
echo -n "$CODE" | xsel -i -b
echo -n "$CODE" | xsel -i -p
xsel -c -b
xsel -c -p
KeepassXC can store them internally as well. So if you want to, secure your database with an additional yubikey, and then store the 2FA TOTP that is supported by more sites in that DB.
I have used this in a script to connect to a VPN where the client will accept stdin. I’m thinking it is in the spirit of OTP being another favour because it’s my device that is generating the required code, even though it’s not a separate device from the one I’m connecting with.
In the days of those physical RSA code generators I had one set up with a webcam pointed at it so I could avoid having to take it with me, but never got around to having something read its display and provide me the number. This was before such things got easier.
For cases in which native Yubikey support isn’t available, I use a Yubikey in static password mode. I append the static password to my normal password. Thus, I still get the benefits of hardware-based MFA even where no support officially exists.
While I’d prefer FIDO2/WebAuthn support. I backup my most-often-used TOTP on my OnlyKey which makes easy to hammer out those codes quickly.