Disable vault-item access in web view
Hi,
We recently started using 1Password for Teams in our company, instead of the old-style 1Password. I love the sharing features, but I have one major concern. The web app allows not only access to admin functionality, but also access to all the passwords in one's vaults. That means that a single vulnerability like cross-site scripting anywhere in your app, can compromise all the passwords in all the vaults of a user. That really scares me. I really want to disable access to vault items from the web app; users are using their Mac and iOS apps anyway. We'd like to use the web app just for admin functionality.
How can we do this?
1Password Version: 6.3.5
Extension Version: Not Provided
OS Version: 10.12.1
Sync Type: Not Provided
Comments
-
Hey @chris_! Great question. With 1Password accounts, there are three umbrellas of security to keep your vaults secure. Before all of them is your Master Password and Account Key. In the standalone version of 1Password, everything is protected by your Master Password and all the security wizardry in the app. But in an account, the Account Key is used to strengthen things even further. If you have a weak password, it's very unlikely someone will be able to access your data because the Account Key is a 128-bit string of characters that's generated locally when you set up your account. It never leaves your device, and we ask that you print it out to have a copy in case you need it later — you're probably not going to remember the whole thing. ;)
It’s great to have a Master Password and Account Key protect your data, but they also need to communicate with the server to access your data, so we use three layers to protect things at rest and in transit. The first layer is based on your Master Password and Account key, which are used to derive a secret that is used to securely encrypt all of your data, both at rest and in transit between your devices and our servers. The second layer is based on the Secure Remote Password protocol. It allows your devices and our servers to make sure they are who they say they are. This provides an additional layer of protection against attack. The third and final layer is the standard TLS/SSL protocol. This layer provides a final layer of encryption and also allows your web browser to indicate that you were communicating directly with a 1Password web server.
We've also undergone third party security reviews and have a very large Bugcrowd bounty program for anyone who can find vulnerabilities. The security architecture of 1Password Teams is documented publicly in our White Paper as well: https://1pw.ca/whitepaper
I hope that helps give you some confidence in the web interface. :) Let me know if you have any questions about it.
0 -
Hi @Jacob, thanks for your elaborate answer!
I have no doubts about AgileBits' commitment to security, and about the sanity and depth of your security measures. As a penetration tester, I've spent some time on your protocols and designs already before trying Teams, and everything looks really sound and well thought-through.
However, as a penetration tester, I also know that no matter how stringent the security measures and strong the security culture, vulnerabilities will occur in code. Sometimes by oversight of a developer, sometimes by introducing a third-party library.
That's why I am really uncomfortable having everybody in our company be able to access all passwords in all their vaults through the web. They don't need that; they have 1Password on their laptops and phones. So it only adds a huge and risky attack surface, while it doesn't really add value.
One simple cross-site scripting or cross-site request forgery vulnerability can now have an enormous impact on our security, if someone with an active agilebits.com session is targeted. And then all the layers of SSL, Master- and Account keys and SRP don't matter anymore: in the browser of an authenticated user, all passwords are readable.
Therefore, I really want to disable this functionality. Please tell me there is a better way to do this than developing a custom browser plugin for our ±100 users that cripples your webapp.
0 -
It's a "feature" we can consider adding in the future, but for now it is not possible for the web interface to be disabled at the account level. Frankly, if we did that, there would be no way to manage vaults or account settings. Someone disabling the web interface would need to do so in the web interface, and as you can probably imagine, that's rather problematic.
I know that's not what you suggested, but if we're talking about logging in with your Master Password and Account Key, the account itself and everything in it is accessible, even if we hide vaults. 1Password's security is built on encryption and not permissions, and by definition, if you're able to login at all, you have the keys. What you're suggesting is like having a lock on an inner bank vault in case someone is able to get into the first one...but they both open with the same key. We could disable the vault view or require you to login yet again to access it, but that's just kind of making you jump through hoops. We should assume that an attacker who's already able to login as you (or has taken ownership of your machine so they can let you do it for them) is smart enough to be able to get around what amounts to artificial (i.e. non-cryptographical) barriers.
Ultimately, you're still susceptible to an attack if the machine is compromised, even if you're using only the app. Anyone who has taken ownership of the machine has the same privileges as you. At that point all bets are off, and any measures we put in place only slow an attacker down rather than preventing them from getting to what you can already access.
A more relevant concern (unless you don't plan to use the 1Password browser extensions either) is the other extensions you install, as these are often granted the ability to access any information in your browser — including the logins you fill, which you thought you were protecting by disabling the 1Password web interface.
But you can avoid all of this by having your team practice good security hygiene. After all, each of us is the weakest link in our own security, and the more we educate ourselves about the risks and the behaviours we need to avoid, we don't end up in the no-win scenario in the first place. Knowledge is power, after all, and that's why we also don't rely solely on our own assessment of 1Password's security, and we involve 3rd parties in that process.
0 -
Thanks again for your elaborate answers. It seems though that we're talking about different risks here.
It's a "feature" we can consider adding in the future, but for now it is not possible for the web interface to be disabled at the account level. Frankly, if we did that, there would be no way to manage vaults or account settings. Someone disabling the web interface would need to do so in the web interface, and as you can probably imagine, that's rather problematic.
Wel actually what I suggested is not to remove the complete web UI, but just to prevent access to vault items from it. Of course vault management needs to happen there as you pointed out.
I know that's not what you suggested, but if we're talking about logging in with your Master Password and Account Key, the account itself and everything in it is accessible, even if we hide vaults. 1Password's security is built on encryption and not permissions, and by definition, if you're able to login at all, you have the keys. What you're suggesting is like having a lock on an inner bank vault in case someone is able to get into the first one...but they both open with the same key. We could disable the vault view or require you to login yet again to access it, but that's just kind of making you jump through hoops. We should assume that an attacker who's already able to login as you (or has taken ownership of your machine so they can let you do it for them) is smart enough to be able to get around what amounts to artificial (i.e. non-cryptographical) barriers.
Well, no. If you have my password and keys, but not access to the encrypted vault items themselves, my passwords still aren't compromised.
Ultimately, you're still susceptible to an attack if the machine is compromised, even if you're using only the app. Anyone who has taken ownership of the machine has the same privileges as you. At that point all bets are off, and any measures we put in place only slow an attacker down rather than preventing them from getting to what you can already access.
Yes, if your machine is compromised, everything is lost. That's why we have lots of things in place to limit that. But we're talking about a whole different class of attack here - one where the user is not compromised, but someone sends him/her a URL to a page in the 1Password webapp that contains a cross-site scripting vulnerability. The vulnerability there is in the webapp, not in the user's machine or software. This is the nasty nature of cross-origin attacks like XSS and XSRF.
But you can avoid all of this by having your team practice good security hygiene. After all, each of us is the weakest link in our own security, and the more we educate ourselves about the risks and the behaviours we need to avoid, we don't end up in the no-win scenario in the first place. Knowledge is power, after all, and that's why we also don't rely solely on our own assessment of 1Password's security, and we involve 3rd parties in that process.
Actually, no. If everyone in my team practices perfect security hygiene, all machines are fully patched and not compromised, a cross-site scripting vulnerability in the web app still compromises our stored items.
So I've been looking at what Agilebtis writes about the third-party assessments. None of them contain a definition of scope or of the method used, which makes anything written in the review impossible to assess for an outsider. Was the webapp checked? Can't tell. Was a common standard used, such as OWASP Top-10 or ASVS, or did they just poke at it? Furthermore, it looks like all 3 reviews are snapshots taken at one point in time, which is still useful, but much less than an audit of security in the development- and operations process.
To summarize, despite everything you described, it only takes one cross-site scripting vulnerability in the webapp against a perfectly secured customer to expose their entire vault. There is no way to prevent this as a customer, while the risk is enormous (especially if you store all your company-accounts for things like finance, HR etc in 1Password). Furthermore, you don't have plans to mitigate this. Is this a correct summary?
Thanks for the time you're putting into these answers. Again, personally I'm a fan of your products and I don't doubt the attention AgileBits gives to security, but the above situation worries me greatly and prevents me from recommending this solution to our company.
0 -
@chris_: Regarding 3rd party testing, if you follow the link Jacob provided earlier, you'll see that that web interface is a big part of what we're asking people to test publicly — anyone who's interested — in addition to the private testing done in the past and which is still ongoing. We recognize that the web interface, if not properly hardened, tested, and hardened again (and so on) represents a huge opportunity for attackers, the likes of which 1Password has never seen before, given its local vault history; so we put a lot of thought into the security model before we even started on the new subscription service, and continue to work to keep it secure.
And again, only the user has the keys to unlock it. So my concern is that is seems like you're essentially asking for a way to login to 1Password.com without using credentials that will allow the user to access their own data. We could superficially restrict access to the vault interface, but once you're logged in you already have the means to access anything which your "keys" will unlock: admin console, settings, personal vaults, and any other vaults shared with your account. And given access to the keys, the web interface is not the only attack vector either. Even if we're able to prevent an attacker from using the web interface to access data they have the keys to, they can just use the app to do it instead.
Can you tell me more about the cross site scripting vulnerability you're referring to? That seems to be a major premise of your comments and feature request. If such a flaw exists in the web app, I think it would be best to fix it rather than try to add additional features — and therefore additional complexity — to compensate for it. That's likely to introduce further issues. The web team will need to look into this.
0 -
Hi @brenty, thanks again for your reply.
It indeed seems that the core of my point is lost in this discussion, given your questions about XSS. With all due respect to your contributions, perhaps it would be wise to include someone with knowledge about XSS/XSRF vulnerabilities in the discussion? I fear that otherwise we won't really get to a point where you really understand my concern.
I am not talking about a specific XSS vulnerability; if I were aware of a specific vulnerability in your webapp I would report it. I'm talking about the vulnerability class called cross-site scripting (XSS), which is a type of vulnerability that we find in almost every webapp we assess. I imagine your development team has had to fix a few in the past, and doubtless will be confronted with them in the future. This type of vulnerability allows someone to under certain conditions access the vault of a victim without having the victim's credentials, by abusing their existing session with 1Password.
Note that in the link you provided about your vulnerability reporting program, XSS is classified "MEDIUM" or HIGH" depending on the specific occurrence.
0 -
Hi, @chris_. Thanks so much for your thoughtful comments. I'm sorry for the confusion here.
We do recognize the nature of XSS and how the use of the vault view in the web app opens an attack surface that is unnecessary for many users. While we are confident that no XSS vulnerabilities currently exist, we have already implemented the functionality you requested.
If you are using a Team account, you can already limit which clients can access a given vault. Just go to the vaults list in your Admin Console and select any vault. At the bottom of the screen you'll see a list of clients where that vault can be accessed, and you can disable the web client there. Note that this setting is per vault, so you would need to set it for each vault individually.
To address the XSS concern itself, we do make use of a very strict CSP which prevents execution of inline scripts and use of the
evalfunction. I'm not a pentester myself, but I would be very impressed to see an XSS attack that works without those two capabilities. The CSP further restricts other assets as well.I hope that helps! Thanks again for your posts. :)
0 -
Hi @rob,
Thank you so much for your reply!
I've found the setting you mentioned. A note for posterity is that you need to enable beta features in your account before you see that list.
Great to hear that you're implementing a strict CSP, that should mitigate many of the real-life attacks.
Your anwers give me a lot more confidence in the use of Teams, thanks.
One last question: I don't see the "Clients Allowed Access" menu in my personal vault, is that by design?
0 -
@rob another remark is that managing client access itself can be controlled through XSS, so perhaps this would be one of those changes where you would require the user's account password (just like for changing the password). Otherwise, someone who has the opportunity to execute an XSS attack would just enable web access first and then proceed with the attack (although he would need to target an admin user specifically for that).
0 -
I'm so sorry, @chris_! I was mobile and wanted to get you an answer, and I forgot that it was still a beta feature. I'm impressed you found it anyway!
I'll ask about the Personal vault. I'm not exactly sure why it wouldn't be available there except that maybe we didn't expect people to limit their own access or something like that. And since you can't see other members' Personal vaults, you can't limit those either.
As for your other comment, I think we're getting beyond what is practical. Once a user has signed in, everything needed to request and decrypt data from the server is available in JavaScript memory. If an XSS attack were possible (again I don't see how given the current CSP), someone operating within the JS context of the page would not really need to be able to display the vault view. They could theoretically simply request data from the server on the user's behalf.
The client access feature wasn't really designed for this kind of situation, and I didn't take that logic to its end when recommending it to you. So it looks like I was just handing you a pacifier, but I certainly didn't intend to. What the feature does do is prevent users from depending on the web client and thus minimizes the chance that they'll attempt to access it. I understand though that people will click links without looking at them.
I'll need to talk this over with our security guru. The issue right now is that we use the same keys to sign in to the admin console as we do to open the web client's vault view. I don't know that we can change that.
Again, I'm really not overly concerned since we've been running a BugCrowd security bug bounty program for months now (almost a year I think?) and we've not had a single XSS issue. That doesn't mean we aren't watchful, but our confidence in our preventative measures has grown over the months.
I hope that helps, too. Great questions!
0
