5 ms·

If that's your concern then I'm afraid there's little we can do to change your opinion and perhaps 1Password isn't the solution for you. I don't mean to sound

by AGKyle 9y ago

If that's your concern then I'm afraid there's little we can do to change your opinion and perhaps 1Password isn't the solution for you. I don't mean to sound rude or anything like that. Just being honest. We have had grand visions of offering portions of our source (notably the cryptographic portions) available for review, note, not open source in the sense you can use it but in a license that makes it available for review purposes. If 1Password.com was the sole solution we offered then open sourcing the entire app would be potentially feasible because our income wouldn't rely on people compiling their own version and editing out the license code. But it makes little sense for us to make that available if modified copies can be made available removing a chunk of our income. For what it's worth, we have over 90 people who depend on AgileBits to provide paychecks so people can support their families. That's a heavy burden when your decisions can impact that many lives. I'm just a member of our team, not a founder or owner or anything but hopefully you can recognize this side of things. We'd like nothing more than to do whatever we can to get users to trust us but there are limits to what we can do and still keep 1Password alive. If you absolutely have to see the code in order to trust an application then there are other options out there, but they won't provide the same level of support, features, or hands off management. These are trade offs you have to make as an individual. Only you can make those decisions for you. Every person at AgileBits uses 1Password, and we design it knowing we will be using it and we are all passionate about wanting our data secure. If we did something to put your data at risk, we did the same thing to ourselves. Just another view of that I suppose. Kyle AgileBits

t0mbstone 9y ago
I'm simply pointing out the elephant in the room. If there is no ability to audit the source code of the password manager, and the source code is managed by a third party company, then for all intents and purposes, the third party company has theoretical access to everything (regardless of what encryption is used). It boils down to trust, and that trust can be violated by a single rogue employee at AgileBits. It could also be potentially violated by a government agency gaining control of AgileBits.
- epistasis 9y ago
  First, I'd like to point out that this concern is completely orthogonal to a hosted service, and has no connection to it. Second, with the inability to check that a given binary came from a given source tree, open source does not help us audit what gets executed. If we're supposing that Agilebits' build process has been compromised, then we're in the same realm as considering a compromised build process for .deb or .rpm.
  - jpgoldberg 9y ago
    [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.
- jpgoldberg 9y ago
  [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.

by AGKyle 9y ago

t0mbstone 9y ago

I'm simply pointing out the elephant in the room. If there is no ability to audit the source code of the password manager, and the source code is managed by a third party company, then for all intents and purposes, the third party company has theoretical access to everything (regardless of what encryption is used). It boils down to trust, and that trust can be violated by a single rogue employee at AgileBits. It could also be potentially violated by a government agency gaining control of AgileBits.

epistasis 9y ago
First, I'd like to point out that this concern is completely orthogonal to a hosted service, and has no connection to it. Second, with the inability to check that a given binary came from a given source tree, open source does not help us audit what gets executed. If we're supposing that Agilebits' build process has been compromised, then we're in the same realm as considering a compromised build process for .deb or .rpm.
- jpgoldberg 9y ago
  [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.
jpgoldberg 9y ago
[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.