Device Restrictions / Offline Cache
I work for an MSP and we are considering 1Password but security is continually a sticking point. There are many good security features in 1Password and the new Security Events API has been a huge step forward, but there are still areas of concern which we struggle to mitigate. There is an odd dichotomy that Senior Management want to ensure users can access passwords in the event of a service outage, but they also don't like the idea of having a local cache.
I understand and appreciate the idea that "If you tell someone a secret, you cannot un-tell them". You cannot control, or see, if an employee has written down the secrets or stored them elsewhere so the only true mitigation is to change the secrets. As others have pointed out, for an MSP, this isn't really feasible. We, of course, will be evaluating what access is needed for each user and limiting the secrets to which they have access in order to reduce the burden, but the reality is that we will never be able to change every password, for every client, to which a user has access, every time a user leaves.
I have been reading various threads by other users, in particular the following:
https://1password.community/discussion/107396/1password-and-offline-vault-access
https://1password.community/discussion/comment/524218/#Comment_524218
https://1password.community/discussion/113535/feature-request-sso-with-azure-ad
One thing I have been unable to definitively answer is the behaviour when a user is disabled/removed and the correct process to follow. I think, if a user is disabled, the offline cache remains on any machines where the app is installed. Would it be correct to assume that, if the machine was online, the user would be unable to authenticate their disabled 1Password account? But that, if the user were to disconnect from the internet, they would be able to log in and access their offline cache? If the user were to remain online and enter their correct credentials, would 1Password detect that the user is disable and remove the cache? Or would the correct procedure be to remove a users access to vaults so that the cache is removed and then disable the user? (I am assuming that removing a users access to a vault will remove the cache for that vault the next time they authenticate)
It is one thing for a user to have an offline cache on a company issued laptop which we will take back on their leaving; it is another thing entirely for that cache to be stored on a personal machine over which we have no control. There currently appears to be no method of controlling the devices on which 1Password can be installed or on which the offline cache can be created (I saw the suggestion regarding keeping the 2FA in IT for provisioning).
Within Azure AD, you can use Conditional Access to restrict authentication to "Trusted Devices". Thanks to @bundtkate, I understand the difference between Authentication and Encryption and therefore why SSO using Azure AD would not be possible and a master password is required. However it would be theoretically possible to use Azure SSO and Conditional Access during initial authentication to restrict the devices on which 1Password can be installed. This would be similar to 2FA where it is only required to authorise the new device and moving forwards you only need your master password to unlock the vault.
Would I be right in thinking that, if we implemented "Firewall Rules" in Advanced Protection to restrict access to our office, users would not be able to authenticate the application and download the initial unless they were in our office? I assume this would have the side effect of users being unable to access the WebUI or update the cache when outside of the office?
I don't understand how feasible this would be but, the ability to restrict the authentication of a new app to specific IPs would probably also provide the desired effect.
Something else I have wondered about offline operations is; are Security Events logged? I realise that this cannot be immediate but, are the logs stored locally and then submitted to 1Password when you're next online?
Any advice/recommendations would be greatly appreciated.
On a semi-related note; can anyone confirm if the 1Password connect-sync container has a complete offline cache of the vaults to which it has access?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Comments
-
Great questions!
0 -
Hi folks!
Great questions for sure; thanks for taking the time to ask, @simonbrown. Having come from an MSP-type operation prior to working here at 1Password, I understand some of these pain points. :)
I think, if a user is disabled, the offline cache remains on any machines where the app is installed. Would it be correct to assume that, if the machine was online, the user would be unable to authenticate their disabled 1Password account? But that, if the user were to disconnect from the internet, they would be able to log in and access their offline cache? If the user were to remain online and enter their correct credentials, would 1Password detect that the user is disable and remove the cache?
Correct. :+1:
Or would the correct procedure be to remove a users access to vaults so that the cache is removed and then disable the user? (I am assuming that removing a users access to a vault will remove the cache for that vault the next time they authenticate)
I don't see how the order of operations would make any real difference here. The fact is that if they have a device that has cached the data, and they keep that device offline while you're offboarding them, they'll still have that offline cache. This would be true regardless of if you remove their access to various vaults first or suspend their account first.
It is one thing for a user to have an offline cache on a company issued laptop which we will take back on their leaving; it is another thing entirely for that cache to be stored on a personal machine over which we have no control. There currently appears to be no method of controlling the devices on which 1Password can be installed or on which the offline cache can be created (I saw the suggestion regarding keeping the 2FA in IT for provisioning).
Yeah, great point. Certainly some of this can be handled through policy, but obviously that only keeps honest people honest. This is an area where I think we could do more, perhaps as you mentioned via integration with SSO providers. As you correctly pointed out this kind of integration wouldn't obviate the need for a separate password for 1Password, but could help enforce policies such as which devices can be used to access the service.
Would I be right in thinking that, if we implemented "Firewall Rules" in Advanced Protection to restrict access to our office, users would not be able to authenticate the application and download the initial unless they were in our office? I assume this would have the side effect of users being unable to access the WebUI or update the cache when outside of the office?
I don't understand how feasible this would be but, the ability to restrict the authentication of a new app to specific IPs would probably also provide the desired effect.Correct. And then if for example some/all users do need to be able to access 1Password from outside the office a corporate VPN might be of help. Perhaps the VPN only allows devices that have been enrolled in MDM to connect. That's a bit out of scope for 1Password, but just making the point there are ways to implement such access controls. :)
Something else I have wondered about offline operations is; are Security Events logged? I realise that this cannot be immediate but, are the logs stored locally and then submitted to 1Password when you're next online?
Yes, that is correct.
Any advice/recommendations would be greatly appreciated.
I would set up a firewall rule as you described, utilize a corporate VPN, and restrict access to the VPN to company-owned devices. Note that this will ultimately likely prevent the offline cache from being removed in some cases, as presumably you'll be disabling their VPN access when you disable their 1Password account. As such their device won't be able to connect to get the message that it should do that removal. But you'll be physically gathering the device from them anyway. :)
On a semi-related note; can anyone confirm if the 1Password connect-sync container has a complete offline cache of the vaults to which it has access?
1Password Connect stores an offline cache just like the desktop clients for read requests. If 1Password.com is offline then reads will succeed but any writes will fail.
I hope that helps!
Ben
0 -
Hi Ben,
Thank you for the comprehensive response! Having this in writing will help me convince senior management that the steps I am proposing will increase security around the product so this is greatly appreciated.
I don't see how the order of operations would make any real difference here.
It wasn't really clear but this question only really applied if the cache was not removed when a disabled, but online, user tried to authenticate. The fact that the cache is removed at that point is exactly what I wanted to hear.
0 -
It wasn't really clear but this question only really applied if the cache was not removed when a disabled, but online, user tried to authenticate. The fact that the cache is removed at that point is exactly what I wanted to hear.
Ah, gotcha. Yes, indeed. :)
Thank you for the comprehensive response! Having this in writing will help me convince senior management that the steps I am proposing will increase security around the product so this is greatly appreciated.
You're very welcome.
Ben
0
