Security and authentication
Comments
-
Can configuration for a shared/team vault (or account) dictate the lock policy in the clients? I don't see any configuration in the admin section to specify the policy for auto-locking. It seems to be left to each user/client to set as they see fit. Such a decision should be enforceable by a policy in central config, should it not?
0 -
@kdnel: It's enforced individually by each app or browser, not at the account level. For example, if you login in Chrome, you can change the auto lock to 5 minutes, but this will not affect the timers set in Firefox or the 1Password app. It's certainly something we can consider for the future, but keep in mind that individual vaults are not locked separately. The account/app locks, with all of the vaults contained therein. An admin setting the auto lock for another user would mean that this would affect their whole account, including their personal vault. That seems like a bit of an overreach, but it's something we can explore.
0 -
Since the data in a team vault belongs to the team (or in our case 'company') and not to individual (even the personal vault since it's presumably meant to store the user-specific account information relating to the team or company systems, not persona data), this type of control is typical, corporate policy in much the same was as an enforced policy on when your computer locks after non-activity or the extension of security policy control of a phone when connected to a corporate Exchange server. These are exactly the types of controls that companies need over systems for security in general and immensely more in the case of the system that contains all of the sensitive keys and password for a company.
Also, the lack of 2F is a concern for us. While the key/password is great for encryption, it doesn't really help to prevent unauthorized access if a computer already containing the key is compromised. Worse, it appears there is no lockout system for a number of unsuccessful authentication attempts.
So there are seemingly two scenarios where a compromised computer is vulnerable with 1Password. First, if a user chooses to not lock the app at all (which is a valid configuration on the Windows client) then should a locked/disconnected session be compromised then the passwords are laid bare. But even if the vault is locked, it seems that a brute force attack is allowed since failed attempts are not used to lock out a user account. Worse, in my testing, failed access attempts don't appear to even be logged.
Please do correct me where I'm not correctly representing the behavior of the product. But if my assessments are correct, this product is not enterprise ready and therefore (regrettably) not a viable product for our team.
0 -
@kdnel: I hope you don't mind, but I've split this off into a separate discussion since it's definitely important, but doesn't quite pertain to 1Password for Windows in particular; rather, this is more about 1Password Teams/Families in general.
We haven't had many requests for account-level controls for locking, but it's definitely an interesting idea we can consider adding in the future.
First, if a user chooses to not lock the app at all (which is a valid configuration on the Windows client) then should a locked/disconnected session be compromised then the passwords are laid bare.
You're absolutely correct. But at that point the attacker already has access to the machine. At that point, would it not be possible for them to install malware to capture data on an ongoing basis, whether 1Password is locked or not? Once the system is compromised, all bets are off. Your 1Password data is encrypted, but it needs to be decrypted in order for it to be useful to you in any way. So when you actually use 1Password — or any software — on a compromised machine, you're potentially allowing the new owner to access anything you can: they are acting as you, with the same privileges.
That's not to say that there isn't an argument and a use case to be made for these features, only that we need to consider them carefully so we understand what benefits they actually offer, and avoid presenting them as a panacea for security. The user will always be the weakest link.
But even if the vault is locked, it seems that a brute force attack is allowed since failed attempts are not used to lock out a user account. Worse, in my testing, failed access attempts don't appear to even be logged.
I think it's important to recognize the difference between "policy" and "security". Of course there's some overlap, but a "policy" of throttling, logging, or locking an account completely can easily circumvented if the attacker has access to the machine — and it sounds like that's what you're talking about. After all, they don't need to try to go through the "front door" and hammer on the lock screen of the 1Password app. The data is there on disk, and they can perform offline brute force attacks on that, regardless of whether the 1Password window says "no". This is just one example though. That's not to say that policies can't be beneficial, but that in the end we need to rely on the security that encryption provides where policies can fail us.
Please do correct me where I'm not correctly representing the behavior of the product. But if my assessments are correct, this product is not enterprise ready and therefore (regrettably) not a viable product for our team.
I don't think it's fair to say that it isn't "enterprise-ready" just because it doesn't currently meet your very specific requirements. After all, many others have found it to be a good fit. However, we'd definitely like to talk about this more to get a better sense of how we might meet your needs in the future. Thanks for bringing this up! :)
0 -
Thanks @brenty. Happy to chat on a call.
You are absolutely correct, the user is always the weakest point. And as you will well know, security in depth is the best strategy... not relying on just one security provision but layers of them. We'd like to see some additional provisions that would further protect access to the data. Perhaps some things for the roadmap.
0 -
@kdnel: Unfortunately we don't have a call center here at AgileBits. However, we're more than happy to help either here in the forums or via email.
You're right that security isn't a single feature; it's a lot of things working in concert. We definitely appreciate your feedback on this, and we'll take that into account as we develop 1Password Teams going forward. And be sure to let us know if you have any other questions, comments, or suggestions. We're listening! :chuffed:
0
