1Password Teams for Managed Service Providers

Nonylus

I work at an MSP and we use 1Password Teams. We love it and naturally recommend it to our clients. Is there a way or a better way to share common 1Password vaults so that our techs and their operation admins share common confidential information without reduplication of data?

Example of when it would turn useful:
On-boarding a user: We create a bunch of temporary passwords for that user (Server account, email account, VPN, Security Key...) that we keep in our 1Password Vault for that company.
The user will change some passwords and save them in 1Password
How wonderful would it be if that information was immediately accessible for both us as MSP and them without having to communicate over less secure means?
All same passwords in 1 place would be so much easier to manage right?

I understand we could "invite" them to become team members on our account so they can access their dedicated vault but they wouldn't OWN that data which is problematic for many reasons. (Legal, termination of contract, ....)
If they get their own 1Password Team account they can use internally and that they OWN, can they invite our Team account (Not individual emails) to access their Vault?

I'm open to any ideas or suggestions. I'm interested to hear how some of use can collaborate with multiple 1Password Team accounts? Or is this concept anywhere in the roadmap?

Thank you

Caribou

---

1Password Version: 6.8.1
Extension Version: 4.6.9
OS Version: 10.12.6
Sync Type: 1Password Team

rickfillion

Hi @Nonylus,

Would that ever be cool. This is a problem that we've been trying to solve. The very first iteration of the ideas we have is available as the beta "Send a copy..." feature, but that only allows you to send an item to a member within your team so that you can securely share a single login without needing to create a shared vault.

Sharing with someone inside of your team isn't that different from sharing with someone arbitrary. We end up with similar technical challenges. So far we haven't liked any of the approaches we've looked at.

There is one area where sharing between teams is trickier than within a team, and that's making you able to confirm that the user and/or team you're looking to share with is actually the user/team you think it is. Tech only does so much to help with this, and this is a problem that we think is pretty important.

Going back to your use-case... There might be ways of doing something without requiring sending at all. What if you created a user for the client on your own team, provided that user with the passwords they needed, then we gave you the ability to split off that user into their own team so that you could deliver that user account to the client. This wouldn't work if you need the ability to get the credentials back if they change any though. Splitting off the account isn't something that's currently possible, but it's a concept we're considering.

Rick

Nonylus

I'm not sure I fully understand the concept. Split-off would mean creating a team member on our Team A (MSP), give him access to all the password for his company, then move that user to Team B (The company) with all the credentials ?

I think I'd prefer the concept of "Shared vault" between different teams. Each team manages their users that have access to the vault. Tricky but not impossible right? :)

beyer

@Nonylus: I don't want to speak for @rickfillion, because he's a heck of a lot smarter in this area than I am, but splitting off an account (when/if that becomes possible) would mean the user would leave your Team and take their credentials with them. You could easily have a copy beforehand, but if they update any items, yours won't get those updates.

I think I'd prefer the concept of "Shared vault" between different teams. Each team manages their users that have access to the vault. Tricky but not impossible right?

This is unquestionably not impossible, heck I'm not sure we've ever said something was impossible. ;) This would be a killer feature, and there's plenty of use-cases that would benefit from this. We do have guest accounts, which can help in some limited situations but an actual Team to Team sharing system is only something we can implement when it can be done in a precise and secure manner.

One major issue with team sharing that comes to my mind (and what I think Rick alluded to) was the system of verifying the user/team that is requesting/giving access is who they say they are. Most access request systems I see apps implemented these days don't have great ways to prevent spam, phishing, and homograph attacks which are obviously something we don't want in 1Password. For example, let's say we have a simple way that I can share a vault to any Team account just by entering the email address of one of their 1Password Admins.

Using a little social engineering, I could probably find the following information about a target:

1. They use 1Password – possibly from something they've mentioned on Twitter or from one of our great reviews.
2. The email address of a 1Password admin account – from their corporate website, I may see who's in charge of their IT department which is someone who is likely to be a 1Password Admin.
3. Their corporate lawyer, accountant, or really any business partner – by searching online records.

Once I'm armed with this information, all I need to do is create a domain that is very similar to a company my target works with, create a 1Password.com account, and try requesting or granting access of one of my vaults to my target. If I'm exceptionally fortunate, I may just happen to request access to a 1Password.com account where the 1Password Admin is very busy and was expecting a request, so they grant me access without a meticulous review. Even if it's only me getting someone to accidentally accept a request to my vault(s), it's then easy for their users to accidentally share sensitive information or the attacker to start adding 1Password items to websites that are set up for phishing. This isn't a very easy scenario to pull off, but a determined attacker could keep trying until it works.

All of this is to say, team sharing is way more complicated than inviting new users to join your Team account. Inviting users is something a 1Password Admin does explicitly or via a uniquely generated invite link (which is further protected by specifying specific domains that your Team should be in complete control of). You'll also notice, even after you invite someone to your Team you still need to confirm access after they create an account. We take this kind of security extremely seriously. As a side note, I personally never want to see some random request on one of my 1Password.com accounts from a random spammer (I get plenty on Facebook).

The door isn't shut on a Team to Team sharing feature, as Rick mentioned, it's a problem that we've been trying to solve. Thanks for your support of 1Password!

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits

Nonylus

I really appreciate your time to answer with detailed information. It's good to feel heard and is what makes a difference. I completely agree you would want to avoid any scenario like the one you described. When thinking about Team account vault sharing, there is also the question of auditing that is critical too:

Let's say Team A (MSP) has an admin account with Team B (Client)
Creating a user in Team B seems to be only way to collaborate with their Passwords, but it doesn't allow us to see which of our users accessed the data. We would have to know which user in our Team A edited/deleted an item for Team B for tracking and quality purposes. To enable proper auditing, Team B would have to invite each of Team A members, which becomes absolutely un-manageable and expensive.

So we do understand its not a simple request. In the meantime, an "out of the box idea" that may resolve part our "MSP specific" role and would be a billing/admin project more than a specific technical feature:
What if:

• We (MSP) referred our clients to start using 1Password
• In return, the MSP gets a "free" admin account to support and share passwords with our clients

I know it certainly is a challenging thing to implement as well. But might be worth throwing the idea out there so it can inspire and be refined. And you love taking on new challenges, right? :chuffed:

Thanks a lot and good luck figuring out that one ! Happy to work with you to find or test ways.

Cedric

beyer

Whether this scenario is resolved using a vault sharing method or through some creative billing changes, it's definitely something we are interested in. We have a lot on our plate, including some pretty cool new features that we can't quite talk about yet. That being said, this is the kind of feature that can both expand and retain our user base, so I can see it happening sooner than later.

Thanks for all your feedback, I'll be sure to share it with the rest of our team!

--
Andrew Beyer (Ann Arbor, MI)
Lifeline @ AgileBits