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.

Interestingly Microsoft presented EverParse designed to produce verified parsers for these sorts of data formats at USENIX Security 2019. https://www.usenix.org/conference/usenixsecurity19/presentat...

But it's only for parsing the data. What gets down with it after parsing can still be buggy.

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.

And now my reply to your first point. Thank you for letting people know that this interprocess communication is readable by something running as root on the user's machine. For those interested in this, please see an article we posted about this back in June: https://blog.agilebits.com/2015/06/17/1password-inter-proces...

We try to be very clear and open about the choices that we've made in our security design, why we made them, and what the implications for users are.

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.

You've asked multiple questions. I'd like to give you a separate reply for each.

I really really don't like talking about how our competitors might do things. (I work for AgileBits, the makers of 1Password). But I can talk about why we picked one security design over a plausible alternative. So here goes.

One way such a system could work is that the browser extension could talk to a process on the provider’s server. Because the server is remote, the TLS secret key would be stored on that remote server, and so would not be accessible to a root process running on the user’s system. This would, indeed, solve the IPC issue as there wouldn’t be any IPC.

There are a few reasons why we don’t operate that way. To operate that we we would end up knowing when and where our customers log into things. But we don’t want to be in a position to learn our customer’s shopping habits or whether they log into ISecretlyLoveNickelback.org. But with the client server model of that way of doing such things, we would be getting lots of that kind of information and holding on to some of it unencrypted.

Similarly, we don’t want to store any information that if stolen from us would enable such a thief to try to make cracking attempts at people’s Master Passwords. Sure PBKDF2 is good, but it only provides temporary protection should the data be stolen. We also don’t want “big” secrets in the browser. Our browser extension never sees your Master Password and only ever has the password for site it is filling for (or learning from). We see the browser as a very hostile environment.

Now there are certain ways around some of those things. And again, I’m not making any claim about how any other product does things. I’m only discussing how a service with the properties you describe might work.

Different security designs expose different sorts of threats. Nobody can really defend against an attacker running as root on their own system, but our more obvious exposure to to running on a rooted machine in this particular scenario is something that we think is worth the security and privacy benefits of our design.

[Note: I have plagiarized myself from https://medium.com/@jpgoldberg/ross-regarding-your-makes-you... as I'm being asked the same questions in different locations]

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.

You are correct that we are vague about the threat model in this case. But please keep in mind that encrypting local data at rest defends against a whole category of "compromise" (i.e., the data stored long term on the local disk being captured) then the case of a malicious process running on the user's machine while the user is actively using 1Password.

Officially our view is "if a malicious process with user privileges is running on the users machine when they use 1Password, there is little we can do".

But sometimes we try to do better. The example I raise is the steps we take to make things harder for keystroke loggers. We won't go to extraordinary measures to enter a battle that we can't win, but when there are simple things that we can do to make things harder for malware, we will.

See the first three paragraphs of https://blog.agilebits.com/2014/08/21/watch-what-you-type-1p... for some sort of attempt to clarify our vagueness about this threat model.

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.

The browser would have to hold on to the shared key long term. Where does it put this?

Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfuscation.

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

We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces...

This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. For the most part, we do try to defend against something where we can. For example, we take steps to make key logging a little more difficult.

In this case, the steps (other than mere obfuscation) that would be necessary to properly encrypt that channel would require that the user be confronted with a "pairing" request and prompt almost every time they restart their browser.

Again, it would be easy to obfuscate this communication, say by using wss; but the private key for that server would still need to be stored en clare on the computer.

There are other approaches as well, but all have unpleasant side effects that risk user data in other ways.

Oh that would be nice. The difficulty is in keeping track of "supported services" and making sure that they haven't changed their password change forms yesterday.

Standardized password change forms would make our lives (and our customers' lives) so much easier.

It's not impossible, but it it takes a lot of maintenance, to make sure that it behaves as expected. And when you are automating password changes you really want to make sure that it does work as expected.

For your second question boils down to "item sharing" versus "vault sharing".

Item sharing is more flexible than vault sharing, but it requires more work to see who has access to what. It also involves many more public key operations. And it makes things more complicated in finding efficient ways of actually getting things to the right individuals.

But as things develop we may switch to something more in line with what you suggest.

Well spotted about the revocation and password change issue.

At the moment, the way we address this is through server policy to prevent the user with rescinded access from getting any new vault data from the server. But as you correctly note, this isn't enforced by the cryptography.

There is a technique, called "lazy encryption" by some, to manage this sort of thing. What would happen is that any time there is a password change or someone is kicked out of a vault, a new key is created for the vault and all changes and new items are encrypted with the new key. The new key will also encrypt the previous key.

With this, someone who still has an "old key" can cryptographically decrypt things that they could have before (but they could have saved those things before), but would not be able to get at new or modified data.

I spoke about this problem (as it applies to things like a password change) in my talk at PasswordsCon 2014 in Las Vegas, which should give you some idea of how long we've been thinking about this problem.

We've got some of the underlying infrastructure in place for this, but as you can obviously see we didn't get this all working by the time of the release of our beta.

But I cannot make any promises whatsoever about when it will actually be implemented.

I remember doing that in the 90s. There was the "password book" locked away in a location I won't disclose in case they still do it that way.

We all used SSH public keys (this was kind of new back then), so really only needed to consult the password book on certain reboots.

It's more of a threat to us than you describe. If a potential team of N people have k members who need a Linux client, then that might cost us N customers, not just k.

The web app runs in Chrome, Firefox, and Opera. But nothing native yet.

Oh. Never mind.

I somehow had it confused with a JavaScript implementation. Not sure how I had that misconception in my head.

Notice I said "almost every other crypto library". I had NaCl specifically in mind with that qualification.

It's no secret how you feel about crypto delivered over the web and run in the browser, but one of the the factors in our choice involved speed and stability of WebCrypto versus <strike>tweet-nacl</strike>NaCl in JavaScript.

NaCl might be a good choice for our transport layer, but we do a lot of encrypting of keys and not just of non-key data. So we needed to make use of .subtle methods every now and then. So if we needed things that NaCl didn't offer, it was simpler to use a single other API/Library than to mix and match.

I am a huge supporter of efforts like NaCl. I'd obviously prefer to be denied the opportunity to shoot myself (and our customers) in the foot than to use tools that are prone to misuse. It would have also been really cool to show off using NaCl. It is the direction we'd like to see the world move. But we couldn't quite swing it this time around.

At the risk of sounding "markety", let me point out the first three bullet points in the overview of our security doc.

\item[True end-to-end encryption] All cryptographic keys are generated and managed by the client on your devices, and all encryption is done locally. Details are in \nameref{ch:deep}.

\item[Server ignorance] We are never in the position of learning your Master Password or your cryptographic keys. Details are in \nameref{ch:SRP}.

\item[Nothing “crackable” is stored] Often a server will store the password hash. If captured, this can be used in password cracking attempts. Your locally held Account Key means that the data we store cannot be used for cracking attempts. See \nameref{sec:account-key} and particularly Discussion~\ref{aside:factor} for details.

A way of summing this up is that we've aimed to designed things so that our data store is not an attractive target. And that means not being attractive to LEAs.

Ah, that is better. No promises (and nothing in the immediate future), but this does certainly remain in the realm of possibilities.

I don't want to speak for the down-voters (I'm not one of them and I think your comment is was a valuable contribution), but when I first saw AD integration requests I assumed that people wanted AD managed Kerberos authentication to 1Password for Teams; and so imagined delegating 1Password for Teams authentication and authorization to a third entity.

Don't get me wrong. I love Kerberos. And in very early planning stages we looked at it quite a bit. But Kerberos is only about authentication. We need client derived encryption keys as well as authentication tokens to achieve our security goals of end-to-end encryption.

I think that there are three issues with WebCrypto that people often conflate. But they need to be looked at separately when judging the security of any particular things.

1. Limited algorithms. This is what has use using GCM instead of a stream cipher for our transport layer. 2. It allows developers to shoot themselves in the foot by not enforcing best practices. 3. It encourages crypto delivered over the web.

If (3) is your concern, then it doesn't matter how good, modern, up to date, the methods are. This objection applies to tweet-nacl just as well.

If (1) is your concern, keep in mind that there is nothing wrong with the algorithms and modes we are using. Sure we had to forego some slicker alternatives, but this is a performance hit.

If (2) is your concern then what is true about WebCrypto is true of almost every crypto library out there. Whether we use libcrypto, CommonCrypto, MS CAPI, etc, we have just as great a chance of "using it wrong" as we do with WebCrypto. WebCrypto isn't worse than most of the alternatives, it is just new enough that we all hoped it would be better than the alternatives in this regard.

So given these three general concerns with WebCrypto, you need to make a judgement about how these play out when evaluating 1Password for Teams.

Yep. There is very definitely a reason. You might not like it, but there is. For the moment we need a client that runs reasonable well in web browsers.

As libraries become more available or the nature of our clients change, we can switch. We certainly look forward to having the smaller keys that ECC will give us.

We are aware of tweet-nacl, but we are trying to avoid the number of external JS libraries we would need. This is why the Teams web app is limited to browsers that most fully support WebCrypto.(Of course our own browser extension for Desktop 1Password runs in more browsers as it does not rely on any crypto itself.)

I admit it is kind of weird using GCM where a stream cipher would be faster, lighter, cheaper. And so we definitely are looking forward to moving to something like that for our transport layer encryption. There aren't any security problems with our current ciphersuites, but we should be able to improve performance by using things like what you recommend.

The 1Password For Teams web app runs in Chrome, Firefox, and Opera.