LastPass compromise - is 1Password affected?

These are very good questions, @gazu, let me start with the short answers.

[Please confirm that] 1Password's extension does not have transmit any invertible encryption keys to the server

Confirmed.

[Please confirm that] Watchtower does not present a URL (other than as saved by the user) for the user to change his password

Confirmed.

[Please confirm that] 1Password does not mix any element of the browser extension with the web interface.

Confirmed for our browser extensions. (See further below for where web-apps are used in perhaps surprising places.)

Longer answers

Disclaimer: First, I need to disclaim any expertise or authority in speaking about LastPass's security architecture and specifics. Everything I might say about them could be mistaken. I have not carefully analyzed LastPass's behavior.

Many of the differences between how 1Password works and (my limited understanding of) how LastPass works arise from our very different histories. We started out as purely local (and supporting using handling their own synching via a third party such as Dropbox). As a consequence, from those early days, we had zero information about any 1Password user beyond a record of their license purchase if they purchased through us.

At the same time, in these early days, our data format (Agile Keychain Format) did not encrypt things like item titles and URLs. This was so that the browser extension (which only talked to 1Password on your local machine) could query to find the appropriate item for the page it was on and to display titles for you before you entered your Master Password. (With the introduction OPVault in late 2012.)

Systems like LastPass faced the same problem of having to match items to user web pages and prevent a reasonable display of matches, but they stored data on their servers and queries were made that way. As a consequence, systems of that nature would send unencrypted URLs to the password manager. Those may have been obfuscated, but they certainly weren't encrypted. This meant that the service operators not only had access to what sites and services a user had logins for, but they would even learn when the user looked up such items. Whether they retain that information is a separate question, but such systems were receiving that information.

We, famously, bragged about not knowing anything about our customers. And so when we launched our service (needed to offer secure sharing features, fairer pricing, and more secure synching among other things), we wanted to keep the same principles, and so built the system so that we have as little information about you as possible.

Early Watchtower as an example

We first introduced Watchtower before our service (we initially did it in response to Heartbleed). The easy (but privacy violating) way of doing so would have been to have a service that we host that 1Password clients would query with various URLs. The problem with that is that we would learn the IP addresses of the users along with all of their websites. Even if we didn't log or record that information, we did not want that information transmitted to us.

So what we did was to create a very paired down version of the Watchtower database and deliver that whole thing to the clients. So your lookup of some domain was only querying data on your own machine. This is a lot more work than the easy way. And quite honestly I don't think that the bulk of our users have considered the privacy concerns or are aware that we've done things the hard way to protect their privacy. But we did things that way because it was the right thing to do. And this has carried through to the current design.

As I like to say, if you have a login for ISecretlyLoveNickelback.org we don't want to know about it, and you don't want us to know about it, and we've designed 1Password so that we can't know about it.

Path dependencies

But if a service that already knew what websites you had logins for were building something like Watchtower, they would have no reason to do it the privacy protecting way. They would do it the easy way. And this would apply to various other similar functions. So when they start to move to doing more on local clients, they have to redo each and every such thing in a privacy preserving way. They are starting out from a much more difficult position when it comes to improving the privacy and security of their users.

So when the article you cite says

LastPass design offers too many loopholes which could be exploited by a malicious server. So far they didn’t make a serious effort to make the extension’s user interface self-contained,

I like to think that they want to do the right thing, but because of their starting position it is very difficult to do. We started from knowing nothing, and we wanted to keep as close to that as possible.

Web app delivery

The 1Password browser extension, which works with 1Password on your local machine, does not need a network connection at all, and so is never bringing in the web app. So my answer above in the short answer is correct. But it would be wrong to leave it at that.

The story is mixed with our other clients. One difficulty with doing things the "hard way" is that it requires building a lot into each and every client. And so some of our clients make use of web views bringing in the web-app. The security risks of having unsigned client code, such as the web app, is documented and discussed in our security white paper. We aren't trying to downplay the risks. Instead, we are trying to mitigate for them. And as the article you cite says

mixing trusted [...] user interface with web applications is a dangerous design choice.

Again, this is not something that happens in our browser extension, but it can happen is some 1Password clients. Because we are aware of the danger, we work to improve the design and reduce the risks. Our continued goal is to reduce reliance on the web app and to better ensure the integrity of it. When our native clients do have to rely on it, they can preform additional checks on the TLS connection and the certificate. This doesn't eliminate all of the threats, but it does limit them. We are working on additional checks. The details differ from client to client both in the checks and the extent to which they make use of the web app.

I cannot speak for how competitors attempt to manage the risks that come from such a mixture, but I do like to think that our open awareness of it helps you recognize that we don't take it lightly and that we work to contain it. Again, some of this may be the result of our history and general attitude toward privacy and security. Our over all security design goal is to keep you safe from insider attacks. It's not that we are planning to turn evil, but if we can design 1Password in a way that keeps you safe in the event of an insider attack, then you are also safe from anyone who compromises us. Securing web app integrity and delivery, as well as reducing dependency on it, is part of that security design principle.

Thank you very much @palant, both for your research and your posting here.

You've hit upon a really difficult issue regarding password managers and other consumer security products. For the most part users do not discriminate based on security, or when they do it is often not based on meaningful comparisons. I don't blame people for not being able to evaluate password managers on security or recognize the meaningful differences between them, but it is still unfortunate. Because security is complicated it is very very hard for people to really evaluate the claims, particularly if they don't even know what they should be asking.

A theatrical example

Let me give you (and everyone reading) an example. 1Password doesn't have a retry limit when unlocking local data. (There are rate limiters and such for authenticating with the server.) We believe that it would be dangerous security theater. It is security theater because serious attacker who has access to the local encrypted data will not be trying to unlock through the 1Password application, but instead will be performing a master password cracking attempt directly against their copy of the data. It is dangerous security theater because such a retry limit would lead people to believe that their master password is protected in ways that it isn't.

Yet that is a security "feature" that we are missing if reviewers at all look at security. Our competitors offer that "feature" even though it weakens the practical security for many of their users, yet we get dinged for it. In my experience the people who most insist on such a features are the most likely to misunderstand what they do and don't provide. We've lost potential customers over such things.

Expert recommendation

As @gazu mentioned, we are recommended by people like Thomas Ptacek. And it is the people who understand security well who are helping to promote good password managers more generally. So I like to think that what we lose in customers through doing the right thing, we make up for in gaining other customers. Not to mention that fact that doing the right thing is the right thing.

The hash was actually being used for authentication when the administrator connected to the system. Not using a challenge-response scheme means of course that this hash doesn't need to be reversed, it becomes the actual password.

Ah, Pass the Hash all over again.

A lot of people, including system designers, don't understand what hashing does and doesn't do for you. And what they are missing in this (and in NTLM) is what counts as an appropriate proof of identify. And so they end up devising systems which are little better than plaintext passwords but somehow feel secure because of the magic of hashing.

In some cases we face a damned if you do, damned if you don't situation with obfuscation. If we leave certain things unobfuscated, we can sometimes get damaging press, but if we obfuscate, we can get (correctly) called out for the silliness of the obfuscation we put in place.

It looks like RememBear hasn't caught up with us yet on this, but as their model appears to be to imitate everything we do, I'm sure that they will at some point. What they do is what we briefly did due to the fact that on Windows we couldn't limit local clients to a web socket to having the same process "owner".

We've since moved to various native messaging mechanisms for the communication between browser extension and the 1Password Agent, which gives us far greater ability to check that the right browser extension is connecting to the right local service.

We didn't really need to do that verification on Mac, as we had `lsof`` and it also took some privileged access to read localhost communication, but we did this on Mac for uniformity with what we needed for Windows. It's amusing that RememBear copied that painful "feature" where it was unnecessary.

And now that RememBear has come up in conversation, I'll mention that we were fully aware of the possibility of imitators when we made the decision to not file patents for some of the technology we developed. While nobody expected such extreme imitation, I don't regret our decision about not going down the patent road. Once you start fighting over patents, everyone loses (except for patent trolls and the town of Marshall, Texas).