1 Item - Multiple Vaults?



  • brentybrenty

    Team Member

    @rsberlo: Thanks for chiming in. Can you clarify what you imagine would be easier about (hypothetically) sharing a single item versus (actually) sharing a vault? Also, can you give a specific example where you "create a zillion vaults for individual passwords"? Even within fairly large companies the odds of never sharing data with the same person twice doesn't seem to be common, so I'm curious.

  • Maybe this is more relevant in mid-sized companies where people are wearing many hats. We are at about 200 employees.

    Today for example, the Team A wanted to share edit access to our company wiki with someone from the Team B. We don't want to give Team B access to all the passwords in the Team A vault, obviously. And we don't want to duplicate the item into the Team B vault, which will then be out of sync for future password updates. So I ended up creating a vault specific to that one item, and shared it with the people team + 1.

    Another example would be sharing a password between two individuals, where we have to create a "John/Susie" vault. This happens all the time, and to be frank, it's likely affecting our compliance as people are much more likely to bypass this process in favor of what's easy.

    In some ways it's just the way people think. In the past (and probably still) people would send each other credentials in plain text via Slack, which we are obviously working hard to discourage. It seems there should be a secure replacement for this use case.

    Hope this helps!

  • brentybrenty

    Team Member
    edited July 2019

    @rsberlo: I really appreciate it! Those are great examples.

    I guess the question I have is then why doesn't sharing a vault work? It sounds like it's just a usability issue, honestly, and that making it easier to share vaults -- or create a shared vault automatically when the user tries to share (an) item(s) -- is really what is needed, not "item sharing"

    If we can continue to use vaults for sharing, we keep the security and usability benefits of that. That last bit may sound absurd to you in your present situation, but hear me out:

    Each vault is encrypted with unique "keys" which is how people in the team no not have access to things they should. I don't think there's no argument that that is a good thing. But the usability benefit is that it's really easy to tell who has access to a vault as a result. For example, let's say you're sharing a vault with Team A and Team B. By contrast, imagine if you had to keep track of who had access to individual items within that same vault instead. Suddenly it becomes more like trying to figure out inherited Unix permissions in nested directories, and, to be honest, that makes my eyes cross. I can't imagine that this is going to be easy for everyone on your team either, and just thinking about how to present that visually gives me a rash. In the "item sharing" future, are we going to have to view a vault's contents and scroll through long lists, sort by "person", etc. to figure this stuff out? It doesn't really scale, in a lot of ways, and it seems to me we'd just be trading one usability problem for another. So we need to consider the non-security ramifications of doing something like that as well. But it's a problem worth solving, and we'll keep brainstorming. :)

    ref: b5/b5#6207

  • I love the idea of auto-creating a vault on sharing a single item! It could be an option in the sharing dropdown (share via 1Password).

    • User clicks share button, selects share via 1password
    • They select individuals or groups from their org
    • Next screen prompts them to name the auto-created vault (maybe with an auto-naming feature like John/Linda)
    • New vault is created and item is shared

    The only issue here is that if the item is already in a shared vault, a solution is needed for this use case. Maybe the item is moved to a new vault that includes all individuals/groups with access to the former vault, with the new people added.

  • BenBen AWS Team

    Team Member

    Thanks @rsberlo. :)


  • I'd like to throw my support behind having this capability. As we move to more dispersed/virtual teams consisting of people working at one site and lots of people clustered remotely around jobs, it becomes harder and harder to manage things using a vault abstraction.
    e.g I have local Tech team that needs access to all things tech (db's, websites, AWS logins, etc.) and we also have remote developers and freelance developers. They have some overlapping needs for access and some new needs. The overlapping needs are causing issues.
    We can't create a new vault for every combination of user groups. And creating groups doesn't help. Which means we now have Tech logins scattered over multiple vaults and people have to remember which vault things are in. Maybe one solution would be to have a linked account across vaults. I get the complexities with keys and encryption, but I think that could be solved with a linked list of connected logins (each login has a linked list to the matching logins) which then allows update across all linked logins that the person changing the password has access to. Sure - its not a perfect solution - if a person, who doesn't have access to the linked logins, updates the password, then the linked logins won't be updated. But that can be solved by a human process that only someone who has access to all vaults would be able to update the passwords everywhere. Not perfect I know. But enough value to make it useful.

  • BenBen AWS Team

    Team Member

    It is definitely a problem we'd like to solve @bernardof. I don't mean to make excuses, but there are a number of complexities. Some of them are on the technical side, such as the problem of keys that you alluded to, and others are more customer facing (e.g. how do we build a UI that adequately conveys this concept). There has been some recent discussion around this internally so the idea certainly hasn't been forgotten, it is just going to take a fair amount of time, elbow grease, and ingenuity to make it happen. I can't promise anything at this point, but I do have my fingers crossed.


  • I'd also weight in for the "linked" ressources between vaults.
    It apparently was in the roadmap 5 years ago : https://discussions.agilebits.com/discussion/comment/116923/
    I totally understand why it makes sense in an architectural point of view (ie: Each vault is encrypted with unique keys), but from an UX point of view you can see that it can create some issues.
    We currently use Vaults as some sort of team or cross-team repositories. ie: Product / Technical / Infrastructure / Management / HR / etc..
    Some services could be used cross-team, for example tools shared between Marketing and Product. This happens frequently.

    At the moment I have to either :

    • Create ad-hoc cross-team vaults, which isn't handy to manage and doesn't really reflect our organization
    • Duplicate the access in vaults, but consequently : I have watchtowers indicating that I use the same password on multiple accounts, red notifications on the item detail, increase possibility of having desynchronized informations etc.. And also it triggers my OCD quite badly ;)

    From a technical/product POV, I suppose you could have some sort of "master" access in a vault, and the other vaults would just be synchronized or duplicated for that ressource, real time or asynch.
    That's just a quick thought, I'm pretty sure you guys can find a lot of very cool technical solutions, as long as the link/share usecase is covered.

    --> As a team user, I want to link an item from a vault to another one, so that I can share an access to other teams/functions without having to handle multiple duplicated resources or messing up my vault organization


  • BenBen AWS Team

    Team Member

    Thanks for sharing @alexisd. ;) I don't have anything further to add beyond what I said above, but we do appreciate the continued feedback on the subject.


  • Upvote

    Hello, we want to migrate from OneLogin to 1Password and we are also very much missing this feature.

  • LarsLars Junior Member

    Team Member

    Welcome to the forum, @vladimir_smartsupp! Thanks for weighing in on this. I don't have anything to announce regarding it at this time, but keep your eye on updates and their associated release notes for the latest news about new features and changes. Thanks for being a 1Password user!

  • As the comments here attest, asking folks to use vaults for item access control is always going to blow up.

    For N users (or groups with identical access needs) there are (2^N)-1 possible sharing groups (https://www.geeksforgeeks.org/number-distinct-subsets-set/). Just coming up with a suitable naming scheme for all these , and manually updating the access per vault is error-prone. Moving items around between vaults to update access rights is also clunky.

    This workaround is also incompatible with the natural, intended use of vaults as a way to store related items. As soon as an item needs ‘custom’ access, it has to be removed from its ‘home’ vault.

    Even on a family account with 3 users (7 permutations) I’m getting bitten by this! —this would certainly be a showstopper for me if I wanted to use 1P across a larger org.

    I’m aware it’s due to a fundamental architectural choice, but it certainly is a real pain point. Some other folks on this thread have suggested workarounds involving making ‘aliases’ and doing cross-vault sync. Consider this post a (long) +1 for something like that.

    Otherwise thanks for an awesome product! The usability is miles ahead of the competition and 1P is a joy to use.

  • BenBen AWS Team

    Team Member
    edited February 6

    Thanks very much for the detailed feedback on this @fbeisn. We certainly understand the pain. As you might imagine we run into similar situations within our own organization. That said, aliases and cross-vault sync probably wouldn't work. Imagine this scenario:

    Bob has access to the Financial vault but not the Operations vault. Sue has access to the Operations vault but not the Financial vault. The Amazon login item for their organization lives in the Financial vault, but is aliased/cross-vault synced to the Operations vault because both Bob and Sue need access to it. Bob decides it is time to change the password for Amazon and updates the record in the Financial vault. Bob doesn't have the keys in order to get that item updated in the Operations vault. The only ways I can see how we could do that would be to:

    1. Give everyone who has the keys to the Financial vault the keys to the Operations vault (and vice versa), but have the server enforce allowing them access to only the Amazon item. I don't imagine this would be an acceptable solution in the eyes of our security team as it significantly reduces our strongest link: encryption.
    2. Only allow editing of the item by someone with keys to both vaults. This creates problems of its own. What do you do in a situation where nobody has access to both? And would that really be an acceptable solution anyway?
    3. Have the server have the keys and when it notices a change to an aliased item it would update it in both vaults. I can say for certain we will not do this. It would put us in a position where we could access customer data, and that is absolutely not a position we will put ourselves in.

    We recognize the problem. The difficulty is in coming up with a good solution that would both address the problem sufficiently and does not compromise our security model. :)


  • fbeisnfbeisn
    edited February 6

    Hey @Ben,

    Thanks for the thoughtful reply.

    I’m not a security engineer, but it seems like a 4th solution could involve a secure message-passing system between vaults. In your example above, when Bob updates the Amazon PW, a (signed) message with the (encrypted) new PW is sent to all the vaults that have a copy of that item. The next time that vault is opened (by Sue) the queue of update messages can be processed, and the PW will be updated appropriately.

    (I.e. the cross-vault updates wouldn’t be synchronous, and the person doing the updating would not have to have access to any of the vaults containing a copy.)

    Of course, now you have a distributed synchronization problem! (Which I will leave as an exercise to the real engineers ;) ). But since you already allow offline access from multiple devices, maybe you have already solved the sync problem... (You could mitigate the sync problem by making link-sharing read-only, but that doesn’t work in the general case because once Sue has the Amazon password she can presumably change the password with Amazon, but will have no means to update the record in 1P.)

    I think this approach could mostly address the combinatorial explosion of vaults: Bob and Sue would not have to create a separate “operations+financial share” vault and manually maintain the permissions there.
    It would also provides a mechanism for item-level ‘read-only’ sharing of information, in cases where that’s useful (sharing a credit card number, e.g.)

    Hope this is helpful! It’s kind of fun to think about in any event :)

  • BenBen AWS Team

    Team Member


    Hope this is helpful! It’s kind of fun to think about in any event :)

    Agreed! I spoke with our VP of Engineering for 1Password.com, Rick, about this, and this was his reply:

    That’s a fun solution, @fbeisn. I think it can be simpler than that though. The tricky part with your solution is figuring out what keys to use for encrypting the message. Our vaults currently only have symmetric keys, so you couldn’t use that. To make it work, you’d need to have the vaults also have public private key pairs I think. Then you’d encrypt the new item with the destination vault’s pub key. But if you’re going that far I feel like you could then build a system that doesn’t require a message queue at all and just have items in the vault be encrypted by the key pair. I might be missing something though.
    A lot of solutions to this problem aren’t conceptually difficult. The challenge lies in how to implement it on top of what we already have and to do so in a manner that causes the least problems with older apps that don’t understand the new way of thinking.


    I hope that helps. Should you have any other questions or concerns, please feel free to ask.


Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file