And I also store them separately. But don't you agree that storing them in 1Password is still better than nothing, as there are still some use cases that you are protected against that way?
No, that's where you lose me. If you're using 1Password to generate passwords in the first place, then I really don't see how using it for TOTP accomplishes anything. To me, it looks like you could literally concatenate the TOTP secret to the 1Pw-generated password and have the same level of security.
In particular OTP codes are intended to be single use they're a ratchet. If a site does this properly then any OTP code you steal from me is not only worthless when it naturally expires, it's also worthless once I use that code or a subsequent code to authenticate. If you used a passive keylogger that may mean by the time you get the key events that OTP is already useless. Likewise for shoulder surfing attacks.
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.
The question is whether there is any point in having an OTP secret if it's stored in the same location as the password.
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.
You've short-circuited by assuming the threat model is a bad guy breaks into 1Password. But there's no reason to insist upon this very unlikely threat model, there are other threats that _really happen_ in which having both OTP and a password under 1Password saves you.
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.
First, I don't agree that if the attackers have access to the password, guessing that they have access to data stored with the password is "very unlikely".
Second, any theoretical advantage still has nothing to do with ratcheting...
First: Fuzzy thinking. The attackers have access to _a copy of the password_. The copy they got wasn't necessarily anywhere near the OTP secret.
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.
> 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.
I goofed by using the word "secret" in the ratchet description after earlier choosing "secret" to mean the TOTP Shared Secret.
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.
Ratchets serve multiple purposes, but they're fundamentally about having a state on both ends that ticks forward per use. TOTP tokens are stateless and "ratchet" is not the right word for only allowing one login per 30 seconds.
