How secure is communication between 1Password mini and the browser extension?
Comments
-
This is a fantastic question!
A lot of people overlook this kind of concern, yet this is an important part of the security of the overall system.
We are still refining the protocol used between the browser extension and 1Password Mini, so we haven't published it yet. It's tricky to document things that are in flux, so this is not documented (yet) the way that our data format design is.
1Password Mini and the 1Password 4 JavaScript Extension (JSE4) can talk to each other securely once they know that that are talking to a legitimate thing. That is, they need to mutually authenticate each other. 1P Mini needs to know that it is talking to the bona fide JSE4 and JSE4 should know that it is talking to the bona fide 1P Mini. Note that I used "needs to" in one case and "should" in the other. That is because there are different threats involved.
If the 1P JSE4 talks to a bogus Mini, there is the risk of it sending passwords you save in the browser to something it should, but the bogus Mini won't be able to extract other information from a tricked JSE4 because the JSE4 doesn't know any secrets. This is a big change from JSE3 and the 1Password Helper in 1Password 3. We have taken almost all of the cryptography out of JSE4, and so are doing almost no encryption in JavaScript. This is one of the unsung security improvements in 1Password 4. The 1P JSE4 no longer stores secrets and it never sees your Master Password. So a deceived JSE4 could never be tricked into giving away the keys to the kingdom because it never has those keys. We have some methods in place for 1Password Mini to authenticate itself to the JSE (these rely mostly on obfuscation, so I will not go into detail about them); but this is not nearly as strict as the other way around.
The other direction is more sensitive. Could something masquerading as our JSE4 trick the genuine 1Password Mini into revealing passwords? Yes. So this is why we use a number of stricter means for 1P Mini to see that it is talking to a legitimate JSE4. One of the major ones is an out-of-band check on the process. Each web browser announces the ID of the source extension when communicating to a web socket. When we receive a request from Safari for example, we are provided an origin like
safari-extension://com.agilebits.onepassword4-safari-2bua8c4s2c. This bundle is unique to the 1Password extension, which allows us to prevent communication with other (potentially malicious) extensions. This is enforced by the browsers' security. So we can trust Safari, Chrome, Firefox, and Opera to honestly report the source extension. Mini will only talk to our extension.The next question in this process is how do we know that the connection is really coming from the legitimate browsers. Anything could call itself Safari act as a web socket client sending Mini the ID that the genuine Safari would. Here 1P Mini actually checks the process ID of what is at the other end of the connection and then uses the OS X codesigning check that Gatekeeper uses to ensure that the application acting as a web socket client is really the official, digitally signed, browser. (Note that this particular check can be turned of in 1Password's advanced setting for those who want to test the JSE in "unofficial" browsers", but we don't recommend that people turn that off.)
You may be thinking that if an attacker has sufficient control over your operating system, they could defeat some of these measures. That is true. But if an attacker has sufficient control over your operating system then it will be so thoroughly compromised that nothing you do on it, in any application, is safe. We can only defend against those malicious attackers who have compromised your system, but are only exercising their power in limited ways. In practice, this actually makes sense. Most malware attempts to get at information in superficial ways that can be defended against, even though the malware, could, in principle replace every security feature of the operating system with something of its own choosing. It is also possible for an attacker to have limited power on a compromised machine. That is, if they are not running with escalated privileges, then we can and do defend against those.
If we find attempts to break the 1Password Mini <---> JSE4 mutual authentication in development, then we are prepared to implement more measures. In particular, something that looks like Bluetooth pairing (or like the shared secrets used for 1Password Wi-Fi sync) could be used between 1Password Mini and the JSE. We would prefer to have 1Password run "out of the box" without that additional setup for users, but if we detect real threats to our current authentication we are prepared to add that sort of step.
I realize that this was both a very long answer and an incomplete one, as it only provided details about one defense against one kind of attack. But that is often the nature of answers to security questions.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Uff - yes, a long answer. And a most understandable answer because I am not a developer! I hope you are right resp. your 'hardcore'-developers do a great job (I am sure they do!), and I see that you care a lot about this (hidden) bridge between 1P mini and the browser.
Thanks, Jeffrey, have a nice weekend!!!0 -
Thank you @claus.
0
