Share single passwords

2»

Comments

  • brentybrenty

    Team Member
    edited September 2018

    @Bjdavis22: Thanks for your reply! It's always good to have a different perspective. And I enjoyed reading Rick's too, as he's coming from the angle of a team manager (sorry, @rickfillion! :lol: ) making sure everyone he's working with on building the 1Password.com service has what they need to collaborate during development. So I think he makes a good point about auditing and decision making.

    I'll go one step further though, and hopefully pose a useful question here: For a while, I've been thinking, "What's the difference between sharing a vault with a single item, and sharing a single item?" (Sort of a rhetorical question for now.) From a technical perspective, it's much clearer because of how 1Password works. I think all of us here in this discussion have touched on different aspect of that, sort of like the old story about the blind men and the elephant: they're all experiencing the same thing, but perceive it differently. For users, it's less clear. (Users should be, I think, "blind" to the technical aspects in the sense that they shouldn't have to care how it works so long as it does — unless they want to, of course.)

    So I guess the question I have for you is, how do you conceptualize sharing an individual item could be more convenient for you? Put another way, what's the workflow you imagine for that? Try as I might, it seem to me that it ends up being essentially the same as the sharing options we have now, as far as the work you need to do: You still need to select what you want to share and who you want to share it with, which is pretty much how sharing a vault works today:

    1. View vault properties
    2. Edit permissions
    3. Grant someone access

    If we look at sharing an item (beta), it's very similar:

    1. View item details
    2. Select the share option
    3. Choose the recipient

    The hypothetical "share item"?

    1. View item details
    2. Edit permissions
    3. Grant someone access

    Sort of a hybrid of the two, based on the discussion so far. So it seems to me that it's more a matter of UI: it just happens that we've chosen "vault" as a secure container within 1Password that can be shared. What if there were just a shortcut to "Create new shared vault with this item"? I realize that isn't exactly what people are asking for here...but if we were sneaky about it and simply called it "Share this item with..." (you could select multiple people to grant access), created a new vault behind the scenes with access for the people you chose, and if we hid the "vault" aspect of it in the UI I don't think anyone would be the wiser. At that point, what's the difference? It really seems to come down to presentation for some people, otherwise we already have that feature. ;)

    As Rick mentioned, no matter what, you still have to keep track of what is shared with whom, and I find that to be the real challenge regardless of what method is used or how it's presented. I doubt I use either current sharing option as extensively as he does, but I find it is much easier to keep track of and manage a shared vault than a shared item. But that's just me. Interested to hear your take on this. :)

  • Luca87Luca87
    edited December 2018

    Any update on this? Unfortunately we are considering leaving 1password for the lack of this feature. And that's really a pity since we love the product.

  • brentybrenty

    Team Member

    I'm not sure I understand. Did you try the item sharing feature? We'd love to hear from you at [email protected] if you have specific feedback about your particular workflow. :)

  • Hi Rick,

    I am in the same situation as other people in this thread. For example, I have created vaults structured around different teams, ie: (Tech Admin, Developers, Finance). The Developers vault contains all passwords necessary for the dev team. Now I have a contractor who is coming on board, and only needs access to the subset of dev team passwords appropriate for his limited scope of work. I have no way to share those few passwords with him from the vault, unless I create a new vault (very impractical) or send him a copy (which will not sync, and so is difficult to manage).

    I really love 1Password, but I don't know how to scale with this rigid sharing system in place.

  • BenBen AWS Team

    Team Member

    Hey @mikecg.

    I think what I would probably do in that case is create a "development-contractors" vault (or similar), giving access to everyone in the developers group as well as this contractor. How would you prefer to see it work?

    Ben

  • 1Password is more intuitive than lastpass which is a great start, but lacking this feature is a nonstarter as a recommendation as an IT business serving business customers. Having two-way sync of shared items is a must for every single one of our clients using a password manager.

    If you have to create invisible child vaults to make this happen within your architecture the so be it, get it done. We shouldn't have to see any of that for it to work. Just attach a child vault to the vault the item currently resides in and keep them synced within the parent account. Share the child vault with the guest user. Boom, you're done.

  • BenBen AWS Team

    Team Member

    Hi @GeekSpeak411

    Could you please elaborate a bit about how the currently available tools in 1Password are not meeting these goals? In what way are you currently using vaults that prevents you from having "two-way sync"?

    Ben

  • In LastPass, we are able to put a credential in a shared vault for staff which 1Password also is capable of. When a contractor comes on board however, a specific login that they need can be shared with them independant of the rest of the vault which they are not authorized to access. The contractor may be with the team for months, or a couple years. As the password gets updated by staff, the contractor continues to have the correct login up until the point that their share is removed, at which point only the staff remain to have access. No extra vaults to think about, and no updating a dozen vaults when you update or change a password.

    This functionality could be replicated in the 1Password ecosystem with a nested “child” vault. When the parent item is updated, the child item could be updated automatically. No user in their right mind wants to create non-synced duplicates for the same account across dozens of vaults. If the password gets updated for any reason, everyone needs to have that updated information. And when it is time for someone to no longer have access, it needs to be simple to remove that persons access by removing the share. Then you can change the password so that person can no longer log in with the credentials they had, and have that updated password is synced to everyone who continues to be authorized.

    A specific example: There are times when a lower level employee such as a paralegal needs to file documents that are above their access level let’s say on a legal drive. Their attorney needs the ability to grant them access to that specific account they will be working with and nothing else for the course of that project, let’s say it will take a week. Now lets say that 2 days after that access was granted (In 1Password this means creating a trunkated share), IT is scheduled to routinely update that password.

    Here’s what plays out with 1Password: The password gets updated, the boss automatically gets the updated password since they are in that vault, and the employee is now locked out of that folder, and cannot do their work, wasting their time and therefore money the business is paying them to do nothing. They go to their boss, their boss got an updated password automatically so they have no idea why their employee didn’t also get updated so assumes the password manager is broken. They then waste time and therefore money calling IT thinking something is broken, and IT has to explain how the item can only be synced to a single vault and instead has to be reshared to the employee tasked with their project possibly creating a duplicate for the employee who will never know which one is the new one and which is the old one. This benign problem has now involved at LEAST three people, two of which are very expensive people, and all of whom already have full workloads. Add on to this the fact that competitors such as LastPass would have avoided this issue entirely and you’ve now lost an hour the attorney should have been billing, you’ve gotten them billed an hour from IT, and you’ve wasted an hour of the paralegal being unable to access their work. That’s hundreds of dollars right there folks and that’s just one time happening.

    Your solution is instead of having this be a one step process, they currently need to instead go through the following steps:
    1) Create a new vault with some indentifying name for this week-long project
    2) add EVERYONE who has access to the legal vault such as partners who need access to that login IT staff who maintain the systems, as well as the paralegal who needs access manually to this new vault. DON’T forget ANYONE or they will be unable to do work, which costs money.
    3) Move the password to this new vault, it will be the only password in this vault.
    4) when the project is complete, move the password back to the original vault
    5) delete the vault created for the project and forget it existed

    Now multiply this process across 5+ paralegals working 50+ projects over a short period of time in addition to contractors, and you have an absolute rats nest of a system. In addition you have now added many hundreds of dollars of wasted money on non-production labor and therefore multiplied the real cost of 1Password by exactly that much. And no one understands what is truly going on outside of IT, and therefore no one is truly satisfied with the system.

    LastPass on the other hand works exactly as they expect, with vault access for permanently priviledged staff, and item level sharing for limited access that can be removed at any time independant of the other items in the vault. This process requires no thought, wastes no time, and costs no money, and since the organization is static folks eventually get a feel for where everything is and get comfortable. Whereas 1Password with it’s rediculous single-password vaults constantly changing means things are never in the same place two weeks in a row and no one ever really knows what is going on with it. It’s a total non-starter.

  • Essentially what brenty posted in September is exactly what needs to happen, there needs to be an invisivble vault created behind the scenes that gets updated with the parent vault. We’ll call this child vault a “share”. There may be a single share, there may be multiple for a single item. The password should remain in it’s properly filed parent vault, and this whole process should be completely invisible to the end user and done behind the scenes.

    Keep in mind that with even 3 partners creating vaults and sharing in your multitude of methods available currently (shared vaults, and truncated shares) it is literally impossible to know within 1Password who all has been given access to things, and therefore impossible for IT to even manually notify the right folks when something gets updated unless we waste time talking to each person individually and hoping they don’t forget anyone. That’s an hour right there, and that single password change has now cost a couple hundred bucks in an attempt to change it gracefully without anyone having downtime.

  • I'll be reaching out to [email protected] about this issue.

    We like everyone else in this thread are facing the same security issues with 1Password: namely, it is very difficult to adhere to the 'on a need to know basis' security principle with 1Password. It's access to a whole vault for the user or no access at all.

    It's essentially a problem of granularity: if granular access control (note: I am not referring to permissions, in this context, take permissions to refer to what is adjustable using custom Groups within 1Password for Bunisess, i.e. the capacity to restrict certain groups of users to only being able to take certain actions) to specific passwords is required then, within the current 1Password conceptual model, one logically arrives at — create 1 Vault per Password. This means that individual passwords may then be associated with individual users. This is, in theory, a great workaround, however, the UI is not built to support it. It also means that one looses the convenience of adding a user to a whole group of passwords simultaneously (great for on-boarding a new team member quickly).

    I am not a cryptography expert so forgive my simplistic solutions but it seems like password data blocks (i.e. a username, password, notes, additional fields etc. etc.) need to be treated cryptographically like a vault with another class of groupings being possible on top of that (analogous to the current 'vaults').

    This would mean that the data model would essentially consist of two classes of objects:

    1. 'Password' data blocks that are encrypted as vaults are now
    2. 'User' identities

    These fundamental units should then be able to be grouped. For example:

    1. A group of 'Passwords' would be a 'Vault'.

    2. A group of 'Users' could be a 'Team'.

    Once these superstructures are added further relationships could be developed. Just 2 examples:

    1. An individual 'User' could be added to a 'Vault' but not be a member of a 'Team'. This would be great of a Contractor.

    2. An individual 'User' could be a member of a 'Team' which could have access to a 'Vault' but access to a single 'Password' within that 'Vault' could be switched off for that 'User' (via a dialogue when adding that 'User' to a 'Vault' for example which displayed a list of 'Passwords' in that 'Vault' with check-marks). This would be great for restricting access to 'pay per use' service that the 'marketing automation person' should not use during short term project that is kept within the 'dev vault'.

    This structure would also address the issue of syncing. If 'Passwords' were an individual data block then they could be unique within a 1Password account. To make a 'Password' appear in multiple 'Vaults', one could simply select, from the 'Password' screen, the 'Vaults' in which that 'Password' appeared. Only one 'Password' object per account means no more sync issues.

    Another enterprise benefit would be being able to filter and report by 'Password'. This would be a report which basically showed a list of 'Users' associated with a given 'Password'. This would be very helpful when auditing access.

    Another enterprise consideration is that really, in an ideal world a product such as 1Password actually shouldn't need to exist (we don't live in an ideal world so I'm verrrry thankful 1Password does exist). Ideally, from a security standpoint, users would have individual accounts for each service they use, administered from within the administration section of a given service or tool. However, the internet is far from reaching a standard for user account administration so many systems either only allow 'Users' or have a very limited 'Admin' --> 'User' structure instead of 'Owner', 'Billing Manager', 'Admin', 'Team Member' etc.

    This avoids centralised administration of passwords entirely.

    Add federated identity services to this mix which can map permissions structures onto services and you have the ultimate in enterprise security (see Expensify's SSO integrations, including a SAML implementation, they're brilliant).

    Of course, not every service has ideal access structures or integrates with federated identity services so 1Password fills a very real design gap, however, it needs to realise that it operates within a broader paradigm and must conform to the access control process within an enterprise. This means giving enterprise customers a data structure that is flexible enough to allow them to map their policies onto 1Password at scale.

    Luckily we are a small start-up of 30 people, we can work around the current inflexibility, however, despite loving the product, as we grow we will be moving away from 1Password due to the lack of flexibility in the data structure.

    If this is indeed an engineering problem, please put your best people on it.

    If this is just a communication problem and I'm just not understanding something fundamental then please point me to an article that explains an alternative way of working that achieves the same goal by different means.

    Throwing your hands up and saying... 'but, but, but it's too hard!' is super lame. No-one ever changed the world by saying a problem is too hard and walking away.

    If the problem is really technically impossible, which I doubt, please at least release a paper explaining where you've gotten to so that so that other smart minds can work on the problem.

    If this is just the fact that a fundamental, ground up architecture change is required, then you better get writing/spending because I'm thinking this issue might even be enough for another start-up to wedge it's way into the market offering this feature alone, by the time you get around to it. Most of this thread would buy such a product... and at enterprise scale too providing plenty of cash to muscle in on your consumer business.

    I really hope this doesn't happen. I love 1Password.

    I don't really need a response, I'm just adding my voice to the crowd and sharing some of the work we've done internally to identify our 'ideal solution'.

2»

Leave a Comment

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