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.
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.
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.