At this point, what is TOTP actually doing for you? If you're using 1Password, it's already generating unguessable passwords for you. Your TOTP codes are literally just an extension of that password.
It mitigates phishing and password reset attacks. It also means you can give access to some account to a friend or family over the phone one time, without giving them permanent access. Also good on non encrypted public wifi or in a company network with a proxy that sees and logs everything.
It mitigates the simplest forms of phishing. If someone is running a proxy server[0] and passing everything along to the real website, token (or SMS) based 2fa can't do anything.
Right, I know that's the obvious response, but what's it really buying you? The rationale I always see is "the server could log the request and my password would wind up in plaintext". But the problem with plaintext password logs is that in a breach, a substantial number of those passwords will be used to credential-stuff other accounts. A breach already requires you to reset all your credentials for that service, and if you're using 1Password, those credentials had no other value anyways.
I feel like I must be missing something here, especially given who I'm replying to, but doesn't it mean that, even if your password is compromised, it can't be used to log into the service which is also protected by TOTP? Regardless of impact on other services if someone reuses their password. So in theory, there's no desperate need for you to reset your password for the service (though of course you should) because it's still protected by your TOTP setup. (Well, unless your current TOTP was leaked and someone reuses your password and current TOTP before it times out, if the service allows that.) Of course, it depends on the nature of the breach. I've assumed the password leak via request logging as you mentioned (and possible leak of single TOTP), but if the seed for the TOTP is also leaked (e.g. DB breach), then naturally you're in trouble!
I'd love a dumbed-down answer to this. Here's where I think 1Password's TOTP is useful:
User creates a strong password in 1Password when signing up for a service. The password is used only for this service. The service stores all usernames and passwords in plaintext. These credentials are compromised without the service knowing. If I'm using 1Password's TOTP then, I think, an attacker is prevented from logging into the service with my credentials. If I'm not using 1Password's TOTP then the attacker can login to the service.
If the service is compromised, you can't trust your TOTP secret (the little binary string from which your TOTP codes are generated) either! The protections TOTP provide in this scenario are all based on magical thinking; that it "feels" secure. But really, with respect to a specific service, if they're compromised, your credentials are worthless and need to be reset wholesale.
It should be noted that the TOTP secret is probably kept in the same database (if not the same table) as the password hashes. I'm surprised we don't see more TOTP secrets in password dumps.
And you reset the password after you find out about the leak- but that may be a long time or even forever after the leak occurs, so with only a password, you more vulnerable.
Not entirely. But 1Password does clearly flag weak passwords and reused passwords (i.e. used for two or more items in 1Password) with a message that's not dismissible.
Similar, when you are using a tool to generate something unique for logon why does it have to be long? 4 characters should be plenty if you do not reuse it.
It mitigates passive attacks: If someone spies me entering the password (by keylogger or in person) they only get my password but cannot login 2 minutes later (TOTP tokens should not be reusable for some time, so even this 1 minute window gets closed).
Right, but you're mitigating an extremely marginal attack (a purely passive interception of a login) and enabling a somewhat more realistic attack, and for what? If you're just doing it to fake out 2FA requirements, sure, do whatever. But otherwise, just use 1Password passwords and skip the TOTP theater.
> Right, but you're mitigating an extremely marginal attack (a purely passive interception of a login) and enabling a somewhat more realistic attack, and for what? If you're just doing it to fake out 2FA requirements, sure, do whatever. But otherwise, just use 1Password passwords and skip the TOTP theater.
Passive interception is not the only possibility. How many password dumps show up each year? Having TOTP enabled, regardless of where it is stored, helps mitigate that threat unless the password that is leaked can also access whatever is storing your TOTP secrets. But if you're using a password manager and reusing passwords, I don't know what to tell you.
Personally I use a TOTP implementation that lets me move the backing store as a file. It's not stored in my password manager, but it's available to me should I need to change phones. That seems like the best of all worlds.
Password leakage is not a marginal problem. I find saved passwords in public browsers all the time. Those with TOTP are much better protected against this as well.
Sadly, I found ones from colleagues that use 1Password and even to me it happened that I clicked save for password that I didn’t want to save in that environment.
Agreed that you don't gain anything if you're using 1Password. But users may be required to set up MFA to access something like GitHub organizations, in which case having it available in 1Password is convenient.
It's true, putting the TOTP in a synced app actually removes the "something you have" aspect of the second factor. Now you've created a way to intercept the "something you have" factor without touching either the user or the authenticating service, so it's just an extension to the "something you know".
All TOTP devices must store the symmetric key, yes. 1Password goes a step further and provides a UI to allow the user to simply copy the symmetric key out of the login record à la a password.
TOTP clients that make opinionated design decisions prohibiting a user from getting at the symmetric key are correct implementations.
That said, if one wants to mandate 2FA for one’s users, TOTP is not the right choice, given it allows users to do the wrong thing.
Reduction of chance for a successful phishing attack. Is it possible for a hacker to get both the password and the TOTP? Sure, but the timing of that is a 30-second window, in which the hacker needs to be extremely sophisticated in order to successfully compromise your account.
This is not at all true, and we’ve dealt with unsophisticated but successful ATO attacks on TOTP all year. TOTP does not defend ordinary users against phishing.
You said attackers need to be "extremely sophisticated" to pull it off, and I've spent a year seeing nitwits – clumsy and trivially detected nitwits – do it without much trouble. You were wrong, and wrong in a way that's important to correct so people know that it's wrong.
