Normally I would reply back and explain, but you know more about this than I do, so instead I will ask a question.
Does it not protect against your password being compromised in some other channel? Sure you're probably not reusing passwords, but what if they compromised it some other way? What if the website had a flaw that allowed someone to exfiltrate plaintext passwords but not get at other application data?
Or to put it another way, if you're using a password manager, why use TPOP codes at all if you believe there are no other attack vectors to get the password that TPOP protects against?
The website and the password manager in this scenario are storing the exact same secrets. If you're going to store them in a password manager, it is indeed reasonable to ask "why bother"?
TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.
> TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.
I was fully in that camp before I started talking with friends on red teams that were allowed to actually start using realistic phishing campaigns. Now I'm fully in the "U2F, client certs, or don't bother" camp.
Maybe I'm jaded, but it feels like the exploit landscape has improved enough that TOTP is as hopeless as enabling WEP on a present-day wireless network. Not only does setting it up waste your time, you're presumably doing so because you have the false belief it will actually offer protection from something. It may have been useful at one point, but those days are disappearing in the rearview mirror.
The only place I see TOTP still offering value is for people who re-use passwords, but only because it becomes the single site-unique factor for authentication.
U2F addresses phishing and password theft. TOTP just addresses password theft. That doesn't make TOTP useless; password theft is a serious problem, routinely exploited in the real world.
But the secrets serve different purposes, they aren't the same. So why not keep them in the same place? I'll admit that it is less secure of course, since someone could compromise your 1Password. But it is still more secure that not using TPOP at all, is not?
Again, is there no attack vector that exists that makes TPOP worthwhile when you're already using a password manager that makes it not worthwhile if it's in your password manager?
I'm not really sure I see how storing TOTP secrets in 1Password is materially any more secure than not using TOTP secrets and just letting 1Password generate a random password for that site.
a keylogger sniffs your password for site X, now they have your password for that site and can log in. If you also had a TOTP code, they can only log in for the next 30 seconds using that TOTP code, but they can't send out an email with your password in a CSV file to their friends and expect it to be usable.
I know I'm wrong because you know everything but I can't get past this particular one. unless the argument is, attackers aren't that lame anymore, then sure.
Best not to assume anyone is infallible. If you don't put people on pedestals you've got less cleaning up to do later when they inevitably fall off. Yes that includes you (and of course me).
2-3 minutes is more realistic for real sites than 30 seconds, because there is usually a margin allowed for clock skew. But yes each OTP expires and that's a difference for an attacker who doesn't know the underlying secret.
TOTP is also not supposed to be re-usable. A passive keylogger gets the TOTP code, but only at the same moment it's used up by you successfully logging in with it. Implementations will vary in how effectively they enforce this, but in principle at least it could save you.
Caveat: The system may issue a long-lived token (e.g. a session Cookie) in exchange for the TOTP code which bad guys _can_ trade unlike the token itself.
I think there's also a difference with passwords on the other side of the equation. If I get read access to a credentials database (e.g. maybe a stolen backup tape) I get the OTP secret and so I can generate all the OTP codes I need, but in a halfway competently engineered system I do not get the password, only a hash. Since we're talking about 1Password, this password will genuinely be difficult to guess, and guessing is the only thing I can do because knowing the hash doesn't get me access to the live system. In this case 1Password is protecting you somewhat while my TOTP code made no difference. If you have a 10 character mixed case alphanumeric password (which is easy with 1Password), and the password hash used means I only get to try one billion passwords per second, you have many, many years to get around to changing that password.
Still, FIDO tokens are very much a superior alternative, their two main disadvantages are fixable. Not enough people have FIDO tokens, and not enough sites accept them.
[Edited to make the password stuff easier to follow]
The scenario of "attacker has a key logger but doesn't steal the entire password database" sounds like enough of an edge case to ignore. If someone's stealing data from my password manager I'm going to assume full compromise.
The issue is with storing your TOTP secret in the same store as your password. The idea of using MFA is that multiple secret stores must be compromised in order to grant access to a service.
If you put your TOTP secret on your phone (or Yubikey), then both your TOTP secret store (that is your phone or keychain) and 1Password store must be compromised in order to gain access to your account. TOTP is useful in this scenario.
If you put your TOTP secret in 1Password along with your site password, then only your 1Password store needs to be compromised. This is the scenario where TOTP becomes pointless.
Do you see any problem with using a phone TOTP authenticator, but when setting it up saving a copy of the TOTP secret in a file encrypted with my public gpg key?
The idea is that if I lose access to my phone, I can decrypt that saved copy of the secret, and load it into 1Password temporarily until I get my phone back or get a new phone and get everything set back up.
Before people started storing their TOTP secrets in desktop applications so they could auto-fill them in their browsers, this question used to be the front line of the 2FA opsec wars. I was a lieutenant in the army of "if you want to back up 2FA secrets, just enroll two of them; a single 2FA secret should never live in more than one place". I think that battle is already lost.
Lots of reasonable people back up their secrets, or even clone them into multiple authenticator applications. I try not to.
> Lots of reasonable people back up their secrets, or even clone them into multiple authenticator applications. I try not to.
Because if they lose access to the 2FA secrets, you lose access to your account. If that's just one account, recovery might be doable (depending on who ultimately is root on the machine). If its your Bitcoin wallet or FDE though, you're toast.
There's also a variety of protocols used for 2FA. I've seen: USB2, USB3, USB-C, BlueTooth, NFC.
As for how people do this: they use a second key, save their key on a cryptosteel(-esque) device [1] (IMO overpriced, YMMV), USB stick, a piece of paper, or gasp CDROM. Where its saved differs. Could be next to a bunch of USB sticks, in a safe, at a notary (my recommendation though does cost a dime or two), in a basement under a sack of grain, ...
Parent's argument is that it mitigates phishing - i.e your normal workflow is you go to a site and your credentials are automatically filled in, so you'd be suspicious if that doesn't happen. In my experience, the autofill breaks so much that I've started copying my password in manually all the time.
Depends on the exact attack. If its a full MITM (including TLS), no. If its a fake website who don't forward after password-based authentication, yes. U2F would also detect the domain is incorrect, though so does my password manager. Though that's based on a browser extension. I suppose if the browser gets mislead, as would the password manager. And that did happen with LastPass (XSS attack IIRC).
Seems like they'd still protect you from anything that records your password and TOTP, but doesn't gain access to your store? E.g. a website gets some JS injected that skims your login. Which doesn't seem all that unlikely.
Basically it becomes "just" replay prevention. Which is a nonzero benefit, but totally agreed that it's not at the same level as a separate generator of some kind.
Does it not protect against your password being compromised in some other channel? Sure you're probably not reusing passwords, but what if they compromised it some other way? What if the website had a flaw that allowed someone to exfiltrate plaintext passwords but not get at other application data?
Or to put it another way, if you're using a password manager, why use TPOP codes at all if you believe there are no other attack vectors to get the password that TPOP protects against?