Security questions

alexisrosen

Having read all your writing on your security model, I have to conclude that when I put a master password in on my.1password.com, it's actually processed locally by javascript only, and vault items are sent only as opaque tokens to your cloud service. But I'm still concerned about using my master password with your web site. It seems to me that the attack surface of my master password is much larger if I use your web site, because if your javascript code is hacked, or falls victim to a supply-chain attack, my master password can be stolen. Without using your website, that potential vulnerability doesn't exist, and the only exposure left (still not small) is if your sources, or your binary distribution, is compromised. (That excludes vulnerabilities not specific to 1p, such as an OS compromise.)

So, first of all, does this analysis make sense, or do you think I'm missing something? And second, assuming I'm right, but I may need to use your web site occasionally, is there any reason not to use a different master password with your web site than with the local 1password?

The reason I think I might need to use your web site occasionally is that it appears that there's no way to manage group memberships and similar features in the desktop client. Am I missing that somewhere?

---

1Password Version: 7.8.1
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

[Deleted User]

@alexisrosen I think your analysis is correct - when using a web app the security of the client code is paramount. However, the same is also true when running 1Password's native apps. jpgoldberg had lots of interesting stuff to say on this in the following thread:

https://1password.community/discussion/120602/

When logging into the website you are not just protected by your master password, 1Password additionally requires your secret key. It also uses the secure remote password protocol which means that your master password and secret key remain local. Unlike other password managers, it doesn't use a hash of your master password to authenticate you. These are the main reasons I use 1Password:

https://support.1password.com/secret-key-security/
https://support.1password.com/secure-remote-password/

Additionally, you can turn-on two-factor authentication so that someone with access to your master password and secret key cannot use these to download your password database.

https://support.1password.com/two-factor-authentication/

I also bookmark the 1Password website and only go there via that bookmark or using the browser extension.

ag_yaron

Indeed, as @missingbits so eloquently explained, there are multiple failsafes to this, including your Master Password and (an optional) 2FA.

Bookmarking our login page is a great way to prevent phishing attempts, though if you use 1Password in the browser to autofill your Master Password, you are also safe since it will not autofill in the false URL. :chuffed:

alexisrosen

I appreciate the responses here.

However they mostly don't address what I was talking about. (The jpgoldberg thread linked above does, somewhat.) I am not (here) concerned with phishing, and I am well aware of the security model and how the master password is never sent.

My concern is that many of the protections described in the jpgoldberg thread are for the clients shipped for Macs, Windows, Android, and IOS, but they aren't directly relevant to the javascript running in my browser when I'm using my.1password.com. There are some equivalent ones - for example, the code won't be downloaded to run in the first place if the web server doesn't have the appropriate cert, which sort-of stands in for the code-signing.

Web apps are generally (though not necessarily) inherently much more susceptible to compromise than traditional ones, because most web apps link in resources from third-party sites in profusion. That means that the app's author is not checking the code before it's used (as you plausibly could with an open-source library that was security-critical). And of course now there are more chances for an attacker to make a successful attack - every separate third party presents a new opportunity.

This is the primary additional threat I was thinking about in my first post and perhaps I should have underlined that more- the supply chain for web apps is typically (though again, not necessarily always) much more exposed than for traditional binaries, with fewer controls in place.

On the bright side, I've discovered that at least some of the features I thought missing in the traditional app are in fact present. So I have a lot less need to use the web app.

[Deleted User]

@alexisrosen Good question. I would be interested to hear what the security team have to say.

You may be interested to read Cure53's report on their pentest of the web based components of 1Password:

https://support.1password.com/security-assessments/

ag_ana

@alexisrosen:

I have passed your question to our security team :+1:

Lars

@alexisrosen - thanks for the questions. You're correct to question the security of anything running in the browser. A browser is typically the most hostile environment on most people's devices. It's main function is literally to facilitate the running of remote code on one's local machine, the very definition of "potentially dangerous/insecure."

I'd be interested to hear what features you thought native 1Password desktop apps lacked that you could only find in the web app; as a rule, I find the web app much more constricted in terms of what I can do with my data. Multiple items, for example, cannot be selected (for obvious reasons), making batch-processing (such as moves, deletions, etc) of data impossible.

Regardless, in terms of the security of the web app specifically, you may wish to have a look at our 1password.com security white paper, specifically Appendix A ("Beware of the Leopard") beginning on page 52, "Crypto over HTPPS." There is a full run-down of the differences in attack surface between using a native 1Password application and using the web app, including some things you've touched on here such as phishing, as well as a list of mitigations you can (and should) take when using the web app.

The my.1password.com index file is always served by one of our own servers, not a CDN. This alone helps reduce the risk of multiple points of compromise. Additionally, critical JavaScript sub-resources are protected by Sub-Resource Integrity (SRI). This greatly reduces the likelihood of the kind of upstream attack you're referring to by allowing site owners to add a hashed integrity element to resources, which specifies that only this code can be run, so that tampered JS code from a malicious third party would not match and therefore would not run. This setup is certainly not perfect, but it is quite good, and much better than it would be without such measures. I hope that -- plus the considerations and mitigations detailed in our white paper against the particular challenges of using the browser for what we do -- have helped to answer your questions and reassure you.

alexisrosen

@Lars The key feature that appears to be missing (it's possible I'm just not finding it?) are the "people" and "invitations" parts of the web app. I could see no way to invite my brother as a guest or give him access to a vault.

SRI is great, and it does reduce the attack surface a lot- I wish it were more in use in general. It can reduce flexibility a lot and can cause service failures if the user of the referenced service doesn't properly account for version changes in that service, but I will assume you guys have a handle on that.

There is, of course, nothing you can do to reduce the dependence on your index file, and the security of your server. I think that that is irreducibly going to make your web app always more exposed than your regular apps. (Actually, there's are things that can be done, but not in-band. For example, you could make your extension a guardian of the authenticity of your index page, but you'd have to have an OOB channel for the extension to pick up auth data. And again, this drastically reduces flexibility.)

I appreciate your answers. I am reassured to the extent that it sounds like you're doing everything reasonable that can be done. I will still avoid the web app where possible, both for the additional attack surface, and because regular apps are generally better (where there's feature parity).

Lars

@alexisrosen

I think that that is irreducibly going to make your web app always more exposed than your regular apps.

I don't disagree, and I also agree that a native application will almost always feel more integrated with the rest of your device, which is why I use ours everywhere I can, and sign into the web app only to perform administrative functions not currently offered in the native apps, such as inviting and managing people and groups, and only from a trusted device within my own network. In my family, there isn't a great need to do such things often, so I can spend most of my time managing and using data in the place that's most flexible, secure and convenient -- our 1Password apps.

alexisrosen

@Lars Good, we're on the same page. And apparently I'm not blind, those features do not exist in your web app. So my last question is, then, do you plan to implement those features in your native apps in the future?

Thanks.

Lars

@alexisrosen - I want to be clear for you and anyone else coming through this thread at a later time that it's not INsecure to use the 1Password web app, just that there are considerations there which make it arguably not as secure as using the native 1Password applications in some circumstances. The question regarding implementing those features like people management, invitations, etc, into the native applications poses a quite-different set of challenges, security and otherwise. I can't speculate about timelines for future features, though I'd certainly say we'd like to make available as much functionality in our apps as we can, securely.