stopping a disabled user from accessing local cache

We currently use 1Password Business for managing shared company logins and it works great.

We are now evaluating rollowing out 1Password Business to all our technical teams for managing shared customer credentials.

However, our concern is that there is no way to restrict where 1Password client is installed and that it stores a local offline cache on every device that it is installed on. This means that a user can install the client on their personal device and continue to have access even after access to the vault has been revoked or the user account disabled (by blocking it from sync online)

Are there any current features or upcoming features to give us more control and protect against this scenario?


1Password Version: 7.3.x
Extension Version: Not Provided
OS Version: Windows, iOS, Android
Sync Type: Not Provided
Referrer: forum-search:stopping a disabled user from accessing local cache

Comments

  • BenBen AWS Team

    Team Member

    Hi @empowerit,

    Thanks for taking the time to evaluate 1Password for your technical teams to share credentials.

    The cache is a core part of 1Password. It enables things like:

    • Offline access
    • Continued use in the event of downtime with the 1Password service
    • Quicker access and less bandwidth usage (only changes have to be synced when you unlock instead of the full data set)

    We could likely make it such that the apps won’t allow you access to your cached data unless you authenticate with the 1Password service but this eliminates 2 of the 3 benefits mentioned above without providing much if any real benefit (more on that below). The difficulty is that doing this could arguably be considered “security through obsecurity” or “security theater.” Even if the 1Password client refuses to read the data there is nothing stopping a 3rd party client from doing so. There is also nothing stopping someone from copying that cache off to another device where they can work on it later. The only real option would be to not have a local cache, so that any time someone wanted to access data it had to be downloaded from the server. This likely isn’t a realistic option based on the benefits mentioned above.

    Additionally, consider that there is nothing stopping someone from making a copy of all of the data they have access to before you revoke their access. Essentially: regardless of their access to the 1Password app/service, they may still have access to that data. To that point... there are some things that simply cannot be solved with technology and instead have to be process driven (e.g. changing all passwords that have been shared with someone upon their termination).

    Does that help? Please let me know.

    Ben

  • Hi Ben,

    Thanks for your prompt response.

    We understand the importance of offline cache and your reasoning for not providing an option to disable.

    Unfortunately, IT Companies (MSSPs, MSPs and CSPs) are being targeted by hackers/cyber criminals as the weak link in a supply chain to get to their customers. It is important for us to put measures in place to protect against both internal and external threats.

    With regards to internal threats, we are trying to protect against:

    • malicious user (eg disgruntled ex-employee)
    • compromised user devices (typically unmanaged devices eg home computer)

    We've setup custom groups and set custom permissions and client settings on vaults, such as:

    • Disable Import & Export Items
    • Disable Copy and Share Items, Move Items & Print Items
    • View and Copy Passwords (for selective vaults with web credentials only)

    This works well to protect against:

    • a user exporting all items and storing offline
    • a user copying or revealing passwords and recording them offline (in excel)

    The idea is to make it as difficult as possible for a user from making their own copy of all login data.
    The above settings achieves this well, however, the offline cache on a local device is where we still have an issue.

    How about for the ability for an administrator to control / restrict what devices a user can install the client on?
    Ideally we would only allow them to install the client on a device managed by the company.

    Alternatively, is there anything we can do with offline vaults that we host on our internal production network?

    Finally, changing every single password when an employee leaves isn't actually an option. There are thousands of login credentials being managed and no automated way to do this - it would take weeks to do this manually.

    We welcome any ideas?

  • Another idea would be the ability for a centralised way for an admin to manage all secret keys. i.e. the user wouldn't have access to their secret key. That way we can control which devices the client is installed on.

  • BenBen AWS Team

    Team Member

    Hi @empowerit

    We don't really have anything to offer in this regard that you aren't already doing. I suppose in theory you could enable 2FA on everyone's account and have IT / admin hold the 2FA secrets. That would effectively prevent someone from setting up additional devices without coming to the people who have those 2FA secrets. That isn't really the intended use of the feature though — it hasn't been vetted for that use case, and as such there may be oddities in doing so that we may not be able to support.

    Beyond that we did recently launch 1Password Advanced Protection, which doesn't directly address this concern, but based on your comments I feel you might benefit from that offering:

    About 1Password Advanced Protection

    Advanced Protection is included with 1Password Business.

    We can certainly leave this thread open in case anyone from the 1Password community has any additional thoughts / suggestions for you as well.

    Ben

  • Hi Ben,

    We've already applied firewall rules and configured 2FA via DUO under Advanced Protection.

    I don't understand your 2FA secrets suggestion. User's need 2FA everytime they login to 1Password, so we can't withhold this from the users.

    If there was a way to withhold the 1Password secret key, then that would prevent users installing on other devices without the permission of an admin user.

    Happy to keep this open to see if there are any other suggestions or additional thoughts.

  • Does creating a local vault on a shared location on our network solve our issue? Or do these details get cached locally as well?

  • brentybrenty

    Team Member

    Does creating a local vault on a shared location on our network solve our issue? Or do these details get cached locally as well?

    @empowerit: No. Definitely don't do that. It's an easy way to get your data damaged, as 1Password will not get notified when it is unavailable, so reads and writes simply fail.

    If there was a way to withhold the 1Password secret key, then that would prevent users installing on other devices without the permission of an admin user.

    That is not possible. It (along with the Master Password) is used to encrypt the data, so it is needed to decrypt it, and therefore will be available in the app when the user is signed into it.

    I don't understand your 2FA secrets suggestion. User's need 2FA everytime they login to 1Password, so we can't withhold this from the users.

    But that is not correct. Two-factor authentication is only required when authenticating, e.g. when signing in on a new device for the first time. So perhaps that helps. :)

This discussion has been closed.