My suggestion for Passpack is ...

"Shared" or "public" groups feature for small groups accounts

Allow members of a Shared Group to see what group they belong to, what passwords belong to that group, and either to share amongst themselves, or designate an group administrator to handle sharing privileges for the group. This would remove the "central repository" aspect of Passpack.

149 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    anonymousanonymous shared this idea  ·   ·  Admin →
    DiDi shared a merged idea: Group Sharing and management of passwords  ·   · 

    16 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • twohawkstwohawks commented  · 

        Yeah, the ability to choose/assign a shared entity within a passcode entry as an administrator would solve a ton of issues (be very liberating).
        ***I think its the single most significant upgrade Francesco's team could do that would propel PP competitive placement among passcode keepers marketed at this level.

        Further, being able to assign a 'group member' as an admin would be even more liberating (but *not* as critical for initial implementation, as sometimes the group thing doesn't apply).

        For now, we have to... 1) require anyone creating new passcodes to transfer ownership to central (the root company owner), then 2) the chief trusted entity at central must check the shares.

        The drawback is that the chief has root access to everything, and so 'everything' cannot reasonably be kept in a central code-repo - some things gotta go elsewhere, which creates more work.

        BTW, shares are transferred if the target owner already has that share in their people list.

        One other comment... for inhouse users I may also deploy KeePass on workstations to make it easier for users to log into their PassPack accounts (since we use 26+ digit passwords and keys). I can maintain their Keepass dbs centrally, making that easy to manage, and individually assigned dbs makes keeping them private (even on shared workstations) simple to do.

        I can use a centrally managed Keepass db with some client-companies, but many of my clients have a blend of remote win/mac/linux clients, making Keepass impractical (not impossible, but it gets chaotic with non-it folk).

        And at the point you run into those few non-windows associates you want to share codes with you realize you would have been better off starting with something more natively cross-platform accessible to begin with.

        It would be nice to hear from the host about this.

      • BasBas commented  · 

        Is there any update on this?
        We are a relatively small company and absolutely do NOT work with a single 'admin' user with a daily task to enter passwords in a repository. We work on different projects, and every project has its own set of passwords, which are usually managed by the project manager or a technical lead. With many different projects now and in the past, having a single admin user just doesn't work for us and it is the only reason why we're not still using passpack (but we want to!).

        Ideally, we would like to buy a 'x user' volume license where every user can enter and share keys with one another, depending on if they're working on the same project.
        If people are afraid this leads to chaos, then just make it an admin setting whether this is possible.

      • James Saint-rossyJames Saint-rossy commented  · 

        I'm specifically interested in being able to see group membership and passwords associated with a group but do agree that the one account centralized approach is hampering our implementation.

      • a_c_ma_c_m commented  · 

        I assumed this was how it worked, purchased PassPack for my Org and now found this ISNT how it works.

        As an admin in an organisation, i need to be able to control who sees what and manage newly created passwords. Needing all new passwords to be entered by me is really defeating the purpose of a tool like this!

        Will trial for a week then probably ask for money back and find another solution.

      • MichielMichiel commented  · 

        Now is only possible to e-mail an entry if you are the owner of an entry. This should be available for more users.
        Either an extra sharing-option visible, changeable, 'mailable' or a right for a certain group.

      • twohawkstwohawks commented  · 

        For business:
        YES - Allow members of a Shared Group to see what group they belong to.

        NO or ToggleSetting - to see what passwords belong to that group. Not necessary, so why do it? What if privilege for me (as an individual) to see "Y" in xyz passcodes for my group is revoked? Some cases perhaps it serves to still let me see the entry in the group code "listing" (but not the contents), but then again other case perhaps not.

        NO - absolutely no sharing amongst themselves - would only lead to chaos: No One but an authorized administrator should be responsible for assigning use of company codes - even if its within a group. The company would lose integrity of authority to manage operations and security.

        How often do you see companies allowing employees to share keys to the office? No, typical protocol is each person is assigned keys only from a central office/administrator that is held accountable for managing all the keys (its a simple auditable protocol), and they are strictly controlled.

        Therfore NO to : Designate a group administrator to handle sharing privileges for the group (since they would be doing it in the first place).

        Order is typically stewarded by a "chain" of command. I think this is what the concept of Central Repository serves... the ability to manage shared privileges without compromising integrity of operations or security.
        Free Sharing of priviledges would only serve to introduce weakness (even chaos) in the order of operations and security protocols.

        Perhaps this would be viable in a system not reliant upon a hierarchal authority structure? Perhaps not? But certainly not in your typical business.

      • CarolynCarolyn commented  · 

        I'd like this too! The small company I work for has an owner, a manager (myself), and a coding manager, all of whom would ideally be able to add passwords to the company account, share, delegate...but not have all those lost if one of the admins leaves, gets sick, etc. Being able to create a free-standing company account with assigned owners/admins would be perfect!

      • PatrickPatrick commented  · 

        We'd like to be able to use PassPack to manage customer passwords. It would be great if we could put all passwords for Customer A into a folder and then share that folder to all people that need access Customer A passwords.

      • CentralmediaCentralmedia commented  · 

        We really need this feature, is essencial for managing a large number of users

      • JanJan commented  · 

        Yes, definitely useful. Currently PassPack is ok but not very strong for managing "real" company accounts. Pre-populating accounts and allowing employees more power (rather than just looking into a central repository) would definitely help.

      • ToniToni commented  · 

        I'm missing this functionality too. We have 5 admins in our company, and it would be great if all of them could add passwords to the groups and share passwords with all the members.

      • DiDi commented  · 

        This is an essential feature for team based management, Passpack without it is only paritially useful and increases overall management tasks.

      • PasspackAdminPasspack (Admin, Passpack) commented  · 

        Thanks for adding this, and for including the link back to our conversation. I'm very interested in to hear if this is a workflow that might be useful to others. We've considered it in the past, and will be happy to consider it again if there's a demand.

      Feedback and Knowledge Base