I understand what you are saying but part of security is making it easy enough that people will use it, but hard enough it isn't easy to break for bad actors. People are lazy in general, if you tell 25 engineers at a startup they have to use two different tools just too handle credentials, the compliance rate of using 2fa will drop to nil, making accounts easier to hack. Don't get me wrong, it isn't like 2fa is so secure, it has been shown to be hackable for sure, especially when using SMS devices; but if done properly it can add a level of extra effort for a bad guy and if that extra effort is easy for engineers to use they'll do it. 1Password makes it this way.

From a corporate standpoint, I don't want people using their personal devices for SMS OTP (2fa) because then if they leave, are disgruntled or get tragically hit by a bus I am locked out of a potentially important service/account. I had this happen on three accounts in the past year where one took me 3 days to recover the ability to access it, another I never could recover and we had to work around it and a third that was absolutely critical but took close to two weeks all said (lots of waiting). That is insane, and all because people used their own personal devices (or similar) for SMS 2fa.

There are other devices you can use, and some enterprises do use hardware keys in addition to the password which works well and the more sensitive the system the more inconvenience people will tolerate and understand.

For me it boils down to 1Password works good for a reasonable price which helps startups and small companies. I also don't think using 1Password is just a tool and you still need a good password refresh cycle and to stop reuse etc. This way if a backup at 1Password was somehow compromised or stored improperly at your company or at 1Password at least you'd be insulated better.

It definitely does provide a single point of access that if compromised in a way which bypasses all their security a lot of companies will be hurting.

> From a corporate standpoint, I don't want people using their personal devices for SMS OTP (2fa) because then if they leave, are disgruntled or get tragically hit by a bus I am locked out of a potentially important service/account. I had this happen on three accounts in the past year where one took me 3 days to recover the ability to access it, another I never could recover and we had to work around it and a third that was absolutely critical but took close to two weeks all said (lots of waiting)

Wait...I've seen two ways for services to handle multiple users from a client using the same account.

1. A company using the service gets a single user login for their account. That login is shared by all of the employees who use the service.

2. A company using the service starts out with a single user login for the account. That login is meant to only be used to administer the account. The administrator can create more user logins for the account, usually with reduced privileges. Each employee is given a separate login of their own, with just the privileges needed to do their job.

I don't think I've seen a #1 that uses 2FA. I assumed that was because it could then easily run into the problem you describe.

With #2 there is no problem using 2FA, or with each user using their own device for 2FA. The only account you have make sure won't be lost if someone gets hit by a bus is the administrator account.

Did you run into a service using approach #1 but that used SMS OTP?

I have for sure run into services that strongly link an account to a person, but don't have a concept of administrative (non-functional) users. Mix this with draconian per-seat licensing and you have a situation where you might reasonably need to store 2FA creds in your vault.

And if you squint a little it's still a 'thing you have' since the vault is something you have to have access to so you can generate the constantly changing 2FA token. It's just a bit easier, in theory, to access than a hardware token or an SMS endpoint.

> I don't think I've seen a #1 that uses 2FA.

Hover (domain registrar) supports 2FA via TOTP or SMS, but it does not support granting multiple users access to manage a single set of domain names.

I suppose sharing the TOTP key along with the account credentials is better than dealing with the issues created by SMS, but it's still not great.

Correct, number 2 in your example is not a problem at all, and we have those as well. But not all services actually support this properly IME. Our policy is to create accounts that are generic with strict permissions around a specific automation or service of our own. This happens more in devops than in everyday usage of say a report tool where shutting off a user doesn't matter.

Essentially my example is the same you pointed out though, for the generic admin account you created you will need to use it to administrate the other users etc. What we do is store that admin account in 1Password with 2fa turned on for it and that way it is never locked to a user with 2fa on their personal device.

For a little more detail too, we will setup sub account for automated systems which have restricted permission (and likely use ssh/key pairs to login for automation). However, when you need to update something about these accounts many times you have to login as them and make a change, so in that case again we store the password and 2fa in 1Password so the team can handle that quickly and isn't stuck because one person left.

I am always open to other ideas though if you think I am missing other options.

In addition to the arguments outlined above, it protects against some attack vectors. If the service gets hacked and the password leaked or they discover the password in some other way, they still don't have the 2FA token and so can't login.

If somebody breaks into a specific service and is able to dump hashed passwords it’s very likely they also had access to TOTP keys. Since you’re already using a password manager you should be protected from password reuse.

Ultimately in this case you are protected from MITM attacks and basic forms of keylogging.

Not relevant to scenarios where you stash TOTP long term secrets in a password store, but note that WebAuthn / FIDO doesn't have this problem - the data you're keeping per user to authenticate with WebAuthn isn't a secret, it's not even personally identifiable, a bad guy could add their own credentials if they have write access, but they can't learn anything by examining yours.

Once you sell services to many different industries, you’ll be out of compliance.

The argument I've seen provided for this is that an attacker would both need your password and physical access to a device with 1password already set up on it.

To use 1password on a new device, you need a "secret key" that is provided to you when you create your account which serves as a basic form of 2FA for your whole account. Not a perfect system, but it is not as simple as just getting your password and having access to everything.

1password is a cloud service. So they'd either need a device like you said or your login/password + authentication key that is only used in the initial setup flow of a new device. So still pretty hard like you said. Never considered how the extra key during new device setup could be helpful until now.

You can also set up 1PW to use a OTP itself. I use 1PW for OTP generation and for passwords (naturally), but my 1Password account itself is protected by my password + secret key, as well as an authenticator/OTP app that is not 1PW.

The "secret key" is of sufficient length to not to be able to qualify as "something you know". It's either a quite lengthy string you have to type in, or a QR code.

I don't use 1PW for teams, but I do use it personally and use it to store all my OTPs except my OTP credential to access 1Password itself. I use a different authenticator app for that (happens to be Microsoft, but that doesn't matter really).

So, while I think it storing storing your passwords beside your OTP generator isn't great, if both are locked behind another factor of authentication, you have mitigated that risk significantly.

There are still good reasons:

1password requires more than just a password to access. You need the encryption key. It acts nicely for that purpose.

2fa is unnecessary if you're generating 20 character passwords uniquely for every site.

The best security is like the best camera. There is no better camera than the one you actually use. This is why cell phone cameras are the best. This is why 1password is the best, because it is security you always use and always keep safe.

It’s not very trivial to gain access to a 1password account:

1. Attacker needs access to the physical device of the account holder if they know the credentials.

2. Otherwise, they need to know credentials + secret key on a new device.

3. You can set up Google Auth to access the account in the first place, which can have its own separate 2fa (this is what we do)

If an attacker has gained access to your vault you have much, much more to worry about than if 2FA codes are there or not.

It's certainly a panic but if everything is 2FA'd with tokens that the attacker doesn't have access to, then you've done a lot to mitigate the splash damage and have a path to regain control.

I just stopped called it 2fa, and just otp for “one time password”, the URI standard calls it otp:// as well

see problem solved, no need to debate how single or two factor a thing is and you can just focus on the attack vectors it actually still solves for, objectively

yes the password vault is a single point of failure if someone knows your vault password or key logs it.