jpgoldberg

To elaborate on what my colleague, Ben, said, we have been in the process moving to more common cross platform code.

A it more than a year ago we had

- 1Password for Mac and iOS written in Objective-C and Swift - 1Password for Android, written in Java - 1Password for Windows, written in C# - 1Password CLI, written in Go - 1Password web-app, in Typescript - Browser extension in Typescript

Introducing new features was an ever more difficult task. Even getting the behavior of things like password strength meters or generators behaving the same across these platforms was increasingly difficult. (Hint, they didn’t behave the same.)

So we have been taking the time to develop a common core of code that can be used everywhere. And this does take time. Writing the common modules is often relatively easy, but we have to get them to work with the platform specific code

Late 2019 was our first successful deployment of any such function, and that was the TOTP calculator. It was largely transparent to users, except for settling on which sorts of TOTP “quirks” we were going to follow. (TOTP standards are a mess, and different Authenticator apps deal with special cases differently. At least 1Password is now fully consistent with itself)

Over the past year, we’ve been plugging more such things into the apps. And it allows us to fix bugs more quickly as well ashen they are in the common code.

1Paaword for Linux is built on all the new/common code. So while it doesn’t have everything that the others do, it is also where you will see the née stuff that is coming.

This has been a huge effort, and the transition has some rough spots, but once we get there we will be able to move much more quickly in developing and refining features and behaviors.

Another reason for the local hosting is so that we (I work for 1Password) are never in a position to acquire secrets can be used to decrypt your data.

I'm hoping that parser generators get more usable. I completely concur that using parser-generators to create safe parsers that will accept all and only valid input is a way to eliminate a large class of bugs.

But getting developers to use parser generators has been a struggle because I'm finding it hard to give dev team tools they can use and integrate into their build systems. It also doesn't help that most developers have forgotten anything they learned about formal language theory, so it's hard to communicate the value of using parser generators.

But we are getting there. Slowly, but there is progress.

[Disclosure: I work for AgileBits, the makers of 1Password]

I'd like to elaborate on the two points made by @epistasis

1. Ability to deliver of a malicious client does not depend on where your encrypted data lives. If you sync over your own private network or if your encrypted data is held by us, it is just as difficult (or hard) to get away with delivering a malicious client.

2. There is a lot of security value to openness and having the source available, but it is only a defense against deliberately malicious software if you compile the software yourself. Otherwise, there is a very weak trust chain between the code that has been reviewed and the binary you are running.

For the first point, a malicious client wouldn't need to exfiltrate all of your encrypted data. It would only need to exfiltrate the credentials needed to obtain your encrypted data. (As well as exfiltrating keys, etc). So for the overwhelming portion of people there is no significant difference with respect to us having your encrypted data or it living some place else.

As for the second point, tools for deterministic builds are improving, but there are still practical impediments. In theory there are ways to ensure a good trust chain between the reviewed source and the binaries that people run. But these are far from ready for our target users: everybody.

So if you, say, recommend KeePass for this sort of reason, are you also recommending it to people who will check the signatures on the source and then build from that? (I have enormous respect for both KeePass and for those who use it that way. But I have less respect for those who would recommend that to everyone. I hope that we are past the bad old days of "some people don't deserve security.")

While we can't completely rule out the possibility of delivering a malicious client (through us turning evil, external compulsion, or an insider attack), there are things that we can do to make it harder for that to go undetected.

You will find that where we can we have made it easy to run 1Password attached to a debugger. People with sufficient skills can see that it behaves as we say it does. This makes it far more likely that a widely distributed malicious client wouldn't go undetected.

Also to support this (and try to gain some of the security benefits of openness), we've gone into gory detail about how 1Password works. Sure there are holes in some of the documentation, but we are slowly filling in those.

I'll also mention the third claim that a "single employee" could cause the distribution of a malicious client. Again, there is no way to completely rule that out, but it would be hard for any single or small group of people do that without running a significant risk of this being detected internally. So it would have to be a fairly large conspiracy. And as we know, the plausibility of any conspiracy diminishes rapidly with the number of people who have to keep the secret. There are many eyes on the source, many eyes on the build and distribution process, and very few hands on the code signing keys.

Several times I've mentioned "significant chance of getting caught". Consider the risks to anyone trying to do evil this way. What are the consequences to them if they are caught, and so how big of a risk will they accept? So even though we can't make it impossible for someone to get away with it, we do what we can to make it hard to get away undetected.

None of this is perfect. And you have to weigh your own choices. But when you do so, make a fair comparison with the realistic alternatives instead of against an ideal.

[Disclosure: I work for AgileBits, the makers of 1Password]

Thanks. I (as you'd expect) agree with both points.

The second one is particularly challenging. Deterministic builds are possible for some categories of software, but it will be a long time in coming. And for software that is updated frequently, it is even harder for people to practically check that what they are running is the reviewed code. But the technology is improving for this to be more practical. On the other hand, app stores move things further away from having the ability to distribute determinist builds.

This is not an excuse to not seek openness, but it does point out that there are lots of things to do that most people don't to get the benefits of that kind of inspection.

It is important to separate three security concerns:

1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS.

2. A browser is a very hostile environment (injected JS, other browser extensions, etc.)

3. JavaScript may not be the best language for coding certain things (e.g., it is hard to remove strings from memory)

Depending on your use, some of these might be larger concerns than others. For us, 1Password.com, (1) is the biggest concern for those using the web-app. Our approach is to be very strict about TLS (TLS 1.2 only, HSTS, etc) and to encourage use of the native clients over the web-app.

I'm giving a separate reply to each of your questions. This is "Couldn't you just pair it once and then be done with it?"

To pair it once would mean that a long term secret would need to be stored. Now we consider ourselves experts at storing long term secrets, but this one would need to be available to 1Password Mini and/or the browser extension even when 1Password is locked. So it would need to be stored on the local machine in a way that is not protected by 1Password.

So an attacker with root privileges (as needed for the loopback sniffing) would be able to get that key. And as I've said in various places throughout this conversation, "encrypting" something with a key that is available to the attacker is merely obfuscation.

Right. This would be unauthenticated with all of the problems that that entails.

And where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would provide no extra security to customers; all it would do is lead them to believe that something is encrypted when it is merely obfuscated.

And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to conceal the security properties from the customer. It would make no difference to the attacker.

Obfuscation would mean that we wouldn't have to have this conversation as often as we do. But it would not make our customers more secure.

Are you suggesting simple DH without any long term secret?

Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.