If you're using 1Password-generated passwords and storing TOTP codes in 1Password, how are the TOTP codes not just theater?
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?
TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.
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?
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.
Most MITM scenarios are going to result in giving up at least one TOTP code -- and that TOTP code will be used to obtain a long-lived HTTP session (I can't remember when Google last had me auth).
I think it's common for folks to think that TOTP means it's safe to lose a code because it is short-lived and invalidated when a subsequent code is used (usually), but it just takes one code for a long-lived session cookie to be obtained.
If an attacker is in the position to intercept your password via MITM, Phising, whatver, they're in position to intercept your TOTP code. They're not going to sit on that code -- they're going to immediately use it to obtain their long-lived session while reporting an error back to you.
Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.
We're not talking about stealing single codes, but the entire secret.
With HOTP the answer is yes, because of ratcheting. A clone of the secret doesn't let you impersonate the original device, because their counters will conflict as both are used.
With TOTP the answer is no. You can make codes freely, and the clone is indistinguishable from the original.
The rule you cite is basically irrelevant. It just means that original and clone can't log in at the exact same time.
Getting obsessed with a single unlikely threat leads to doing things that are actively counter-productive, because in your single threat model they didn't make any difference and you forgot that real bad guys aren't obliged to attack where you've put most effort into defence.
Second, any theoretical advantage still has nothing to do with ratcheting...
If I tell my phone number to my bank, my mom and my hairdresser, and you steal it from the hairdresser, this doesn't give you information about my bank account number, even though the bank stored that with the phone number.
Bad guys successfully phish passwords plus OTP codes. We know they do this, hopefully you agree that in this case they don't have the OTP secret. So in this case 1Password worked out as well as having a separate TOTP program.
Bad guys successfully steal form credentials out of browsers using various JS / DOM / etcetera flaws. Again, they get the OTP code but don't get the OTP secret regardless of whether you use 1Password
Bad guys also install keyboard monitors/ logs/ etcetera. In some cases they could just as easily steal your 1Password vault, but in other cases (depending on how they do it) that isn't an option. I believe it's "very unlikely" in reality that they'll get your 1Password vault unless it's a targeted attack.
A passive TLS tap also gives the bad guys the password plus OTP code but not the OTP secret. Unlike the former three examples this is going to be very environment specific. Your work may insist on having a passive TLS tap, and some banks definitely do (this is why they fought so hard to delay or prevent TLS 1.3) but obviously your home systems shouldn't allow such shenanigans. Nevertheless, while the passive tap can't be used to MITM your session it can steal any credentials you enter, again this doesn't include the OTP secret.
Second: A ratchet enables us to recover from a situation where bad guys have our secret, forcing the bad guy to either repeat their attack to get a new secret or show their hand. TOTP lets us do this when bad guys get one TOTP code but not the underlying TOTP secret.
I'm just going to focus on this, because it's not based on opinions of likelihood but simple facts. TOTP does not have a ratchet. If you copy the secret, you can use it indefinitely.
A ratchet is a counter (or similar) that goes up per use, so you can detect cloning. TOTP does not have this. It does not store any state. If I log in every day, and the attacker logs in every day, you can't look at the counters to see that something is very wrong, because there is no counter.
In the situation we care about (which you think hardly matters, but I believe evidence shows to be extremely common) bad guys do NOT have the TOTP Shared Secret, it's in your 1Password Vault and the bad guys can't access that.
What they do have is a code, a One Time Password typically six digits long.
Because TOTP produces a _One Time_ Password, if I use that code, or any subsequent code, the one the bad guys have is now useless even if it has not yet expired. This forms a ratchet.
Ratchets aren't about detecting cloning, they're about what happens if bad guys temporarily get access. Can we recover? In many systems we're permanently screwed, if there's a ratchet we may be able to recover. For example this is essential to the design of OTR and the Signal Protocol.
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.
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]
In the threat scenario we're discussing bad guys aren't "stealing data from my password manager" they just have the password and OTP code that were filled out, possibly by hand. They can do this using the same tools and techniques that work for password-only authentication, including making phishing sites with a weak excuse for why the auto-fill didn't work. We know this works.
Possibly by hand? You are definitely not discussing the same scenario as everyone else. They're talking about password and OTP being stored in the same password manager, both filled out at the same time all in software.
A key logger is stealing those bytes right out of the password manager's buffers. It takes more sophistication to dump the database, but it's a very small amount more.
In the real world users go "Huh, why didn't my autofill work? Oh well, I'll copy it by hand".
A "key logger" logs keypresses. That's all key loggers do. There are lots of interesting scenarios that enable key logging. You've imagined some radically more capable attack, in which you get local code execution on someone's computer, and then for reasons best known to yourself you've decided that somehow counts as a "key logger". I can't help you there, except to recommend never going anywhere near security.
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.
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.
Lots of reasonable people back up their secrets, or even clone them into multiple authenticator applications. I try not to.
Could you elaborate on how you do this in practice?
Any one gives you access. So you take one with you and put one in a drawer at home.
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, ...
https://www.kickstarter.com/projects/zackdangerbrown/potato-...
https://en.wikipedia.org/wiki/Juicero
etc.
> How is this not an insane product concept?
I thought sanity died years ago.
FWIW, this has not been my experience with 1Password at all.
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.