I am cognizant of this risk, and assume it, because security is always a spectrum between Secure and Convenient. If I had to pull out my phone every time I wanted to use 2FA, I for sure would not be so liberal to turn it on for all the "low value" properties the way I do now
I have never even _heard_ of someone having their 1P master password compromised and the vault(s) exfiltrated (although I grant you it could be just because the NSA doesn't write blog posts about their pwn2own victories)
It's my recollection AgileBits is also running (that is: currently) a CTF with a publicly exposed vault, so folks can test the resilience against attack for themselves
> I am cognizant of this risk, and assume it, because security is always a spectrum between Secure and Convenient.
Absolutely. But also, in such setup, the security benefit of 2FA/OTP codes are negligible at best since there are no conditions under which only one factor could be compromised without also having the other factor leaked (assuming you're using unique passwords for each identity, which is the entire point of a password manager).
However, I suppose it could be used for bypassing the inconvenience of mandated 2FA scenarios (to the dismay of your company's security team).
> there are no conditions under which only one factor could be compromised without also having the other factor leaked
Man in the middle attack,
Phishing attack,
Over the shoulder attack,
Brute force attack,
Keylogger,
Http (not https) traffic sniffing,
'Breech' of the site and realisation they host their passwords in clear text on an unsecured db online.
Then there is human error; typing password into wrong site, giving your password to the tech support cold caller, telling someone your supersecret password ...
> Man in the middle attack
> Http (not https) traffic sniffing
If you can see the password, you can also see the time-based OTP, and you can use those to gain access.
> Phishing attack
> Over the shoulder attack
If you can convince someone to provide you their password, it's highly likely you'll also be able to convince them to also provide you their time-based OTP.
> Brute force attack
A successful brute-force attack on the vault (unlikely) means you've lost both your password and your OTP secret. A sucessful brute-force attack against a remote account using a safe password (re: password managers) is very unlikely!
> 'Breech' of the site and realisation they host their passwords in clear text on an unsecured db online
The password and the OTP secret themselves have no value (given that you're using unique passwords for each account). If the attacker has breached the service back-end then it's gameover anyways, regardless of 2FA for user accounts.
> But also, in such setup, the security benefit of 2FA/OTP codes are negligible at best since there are no conditions under which only one factor could be compromised without also having the other factor leaked (assuming you're using unique passwords for each identity, which is the entire point of a password manager).
Phishing and good ole fashioned human error are two methods by which a password can be leaked without exposing the 2FA token.
I previously thought that we were just having a difference of risk tolerance, but if you think some rando can _phish_ a TOTP secret, we are not even in the same universe of risk mitigation
> Hello, dear sir, this is the USA IRS and we are going to send the FBI because your TOTP code is expired and are going to put you in jail if you don... hello? hello?!
For passive phishing (e.g. setting up an identical website to the real one) stealing a valid TOTP token is trivial and such campaigns have already been spotted in the wild [1]
> if you think some rando can _phish_ a TOTP secret
Given the context this discussion is about (someone with a 1Password vault, storing unique passwords and TOTP secrets for each account they have) do you see any scenario in which a user gets his password stolen but not the token (or the OTP secret seed altogether)?
> Hello, dear sir, this is the USA IRS
If an attacker via a phone call is able to get the victim to (a) unlock their 1Password vault, (b) spell out their password for account X, what makes you think they couldn't get them to also (c) open their 2FA app and spell out their TOTP token?
> I previously thought that we were just having a difference of risk tolerance
The point I was making is that there are no security advantages to setting up a time-based OTP as a second factor for authentication if the secret seed is going to be stored in the same vault where the passwords are: might as well just forego this TOTP setup altogether and save the extra hassle. Or get a hardware second-factor (TPM, Google Titan, Yubikey, ...)
If my password vault is compromised it's game over anyway. There's enough access in there to remove the 2FA on all of my accounts even if you didn't have the codes. There's no way I'm giving up breakglass access and risking locking myself out of my accounts permanently or while I'm on road if I lose my phone.
The point of using 2FA for me is to protect me against my password being compromised since it's a long_lived access key.
I believe there's barely no benefit to setting up a TOTP 2FA for those accounts if you're going to store the backup codes/token seed along with the password in the same vault.
> If my password vault is compromised it's game over anyway.
There are ways you could make a vault compromise not mean a complete/irreversible takeover, but that would either give up breakglass access as you say or add complexity and reduce availability.
> The point of using 2FA for me is to protect me against my password being compromised since it's a long_lived access key.
In which situations on your setup would a unique password compromise not imply there's also been a TOTP token/seed compromise?
Until your vault is somehow compromised and your second factor is no longer distinct from the first one...