PRISM and cloud syncing security
Comments
-
Thanks for your further insights Jeffrey. It's the complexity of the situation that makes it so fascinating as well as scary and repugnant.
Personally I think it is great that you are willing to share some of your personal views on this. I always value the honesty of the 1Password staff and forums. If nothing else it makes me feel more trust for your product. But mainly it is just interesting:-)
Have a good weekend all.
0 -
What about a "paranoid" mode where the user trades off slower operations for higher encryption? (more bits, more rounds, etc)? I'd use that.
0 -
Agree with MikeMcFarlane #62
0 -
@jaydisk #47—
I'm a MoneyWell user too. I assume you know—because No Thirst documents it very clearly—that MoneyWell's Mac data files are not encrypted, even if you set an access password. Unless you store your data in an encrypted volume, it's vulnerable to anyone who accesses your Mac. I haven't bothered to move my Moneywell data to an encrypted volume, but the folder in which it resides is backed up with SpiderOak (not Dropbox!!).
If you set up sync between the desktop and iOS MoneyWell apps, you have to supply a sync password, and I've been told that the sync files (which, like my 1Password keychain, are hosted on Dropbox) are securely encrypted. This gives me some basis to hope that my MoneyWell data, like my 1Password data, is PRISM-proof. Needless to say, anyone who can crack open my Agile Keychain will have my MoneyWell sync password too, but that would be the least of my problems.
Also, I use a password to lock my iPhone, not a four-digit PIN that can be bypassed in 20 minutes.
0 -
I hope that the default setting that would upload all your 1Password data to iCloud the first time you start & login to 1Password on ios has/will be changed to 'off' instead of 'on' now...
0 -
I think a manual option/choice rather than automated secure syncing over encrypted wifi option on our routers is still the preferred option. I say manual because we can choose when to sync when we know we are connected to a secure wifi connection or maybe even 1password could check to see if the wifi connection is encrypted...but still give us the option to do the sync manually if we think it's safe too do so.
or maybe this option for Mac's using "Air Drop" between apple devices (computers and iOS devices). iOS 7 will include airdrop support so something to think about all the latest apple laptops/imacs have airdrop enabled. Not sure what other options Windows would have similar to AirDrop other than an adhoc wifi setup for this.
0 -
@toasty wrote:
What about a "paranoid" mode where the user trades off slower operations for higher encryption? (more bits, more rounds, etc)? I'd use that.
More bits and more rounds do not add meaningfully to real security once you have "enough". Once you reach a certain number of bits and rounds, the security gain from increasing those is negligible. You are far far better just making your Master Password stronger. Even adding a single randomly chosen digit to the end of your Master Password adds more security than going from 30,000 PBKDF2 rounds to 240,000 rounds.
As for number of bits, we have been moving to 256 bit AES keys, but again that is not for the reasons you might think.
I know that there are a lot of people who would feel more secure with upping these numbers or with having a cascade of different algorithms, but something that increases people's sense of security while actually making no meaningful improvement to it would be security theater.
What's peculiar about that instance of security theater is that it is demanded by smart, well-informed end users instead of something offered by politicians or vendors. But it is security theater none-the-less.
I'm not trying to dismiss your suggestion, @toasty, but I hope you can see what that is not really a line I anticipate that we will pursue. Of course we do have "agile" in our name, so anything is possible.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
You are absolutely right, @Davide, that defaults matter a great deal. This is something that people often don't recognize in designing security systems. Our goes is to make it easier for people to behave securely than insecurely, and so our choice of default settings are always considered in that light, but ...
I hope that the default setting that would upload all your 1Password data to iCloud the first time you start & login to 1Password on ios has/will be changed to 'off' instead of 'on' now...
We've changed defaults for security reasons in the past, and I'm sure it will happen again, but I can't promise that we will do this one.
Keep in mind that while we very much agree that people should have more control over their own data and are working to find a way to give you more control, we also don't fear putting encrypted 1Password data on Dropbox or iCloud as much as those of you who wish to disable that.
Also keep in mind that the default sync to iCloud acts as a backup mechanism. Data Availability is an often overlooked part of data security. Contrast the harm of someone getting a hold of your 1Password 4 Cloud Keychain Format data versus the harm of you losing access to it. (Yes, that is not the choice we are facing, but I'm pointing out that we need to weigh in those sorts of data security questions as well.)
I'm not telling you "no"; I'm just outlining our rationale if we do end up keeping the default as it is and why I am still inclined to stick with our default.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
What's the status of USB syncing? Has it been updated since February? Is it still being actively developed?
0 -
Hi @jpgoldberg,
Thanks for this great thread discussion.
You mentioned in your detailed comment discussions.agilebits.com/discussion/comment/72325/#Comment_72325
Revive WiFi syncing.
We really had very very good reasons to drop WiFi syncing with 1Password 4 on iOS. But if it turns out that it is still the best way to enable
people to synchronize their 1Password data wihtout having to store their data on systems beyond their control, then we wouldn't rule out
reviving it.Can you pls explain what the very very good reasons were? WiFi syncing was working fine with me, was reasonably convenient, and kept the data within my devices as I would prefer. I seamlessly did multiple two-way bi-directional sync's (iMac<->iPhone, iPhone<->Macbook, and if necessary, one final iPhone<->iMac; yeah, then I have to sync my other iOS devices as well, but at this point both computers have all updates from all devices; I only add new passwords/info from a single primary iOS device). I realize I should be able to do the same with the USB tool currently under beta since Feb, but I am curious to understand the reasons behind dropping the WiFi syncing.
I have literally kept a spare iOS device with 1Password 3.x just to use it as a syncing medium :) I will give the USB sync a try, but of course having to use a cable further adds to the inconvenience of having to do multiple 2-way syncs.
Regardless of the discussions on the security of the data, I am not willing to give up control of my data for the seamless convenience of public cloud multi-way sync. This is one of the key reasons I choose to pay for 1Password vs. use a (mostly) free solution like LastPass.
Thanks and best regards,
Maged
0 -
Hi @Maged,
First thanks for pointing out that WiFi syncing was working well for you. One of difficulties we face is that we mostly hear from people when things are not working. We knew that WiFi synching was causing a lot of problems for a large number of people, and this were problems that were difficult to sort out, often having to do with the very specifics of people's home network topologies. Also automatic wifi sync failed silently. When it failed people were often unaware that their data weren't syncing.
Please keep in mind that other than knowing how many people have purchased 1Password, we have absolutely no information on how you use it. Quite frankly we simply didn't know how many people were using is successfully.
We also would like to have a sync solution that works across platforms. Wi-Fi sync was Mac only. In principle we could have tried to get this working for Windows as well but at the cost of having to bring in Bonjour libraries. As we saw WiFi sync as something that often caused for difficulty for people than it was worth, we weren't enamored with the idea of extending that to Windows. (I have to confess that it took me a lot of time today figuring out how to connect my wife's Windows laptop to a new WiFi network.)
As I said, we may revive it, but we need to find ways to make it more robust and easier to support.
Both you and @jaydisc have asked about development of the USB syncher. As you've noticed development has stalled. That doesn't mean that we are abandoning it, but instead we are working to bring 1Password 4 to additional platforms.
Keep in mind that because of the design changes from the Agile Keychain Format and the 1Password 4 Cloud Keychain Format, make the latter much for suitable for life in the cloud.
I'm not sure if you will be happy with what I've said here. We've since learned that there are a lot of people who really loved and depended on Wi-Fi synching. Again, I won't hint at what our currently leading candidates are for the kind of cloudless syncing people want, but we have learned our lesson that people really do want this.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Thanks very much for taking the time for a quick and detailed response. I can imagine how difficult troubleshooting people's infinite WiFi networking scenarios must be. I am surprised so many people have problems with it as it works for me both on my home network and at my corporate network which is a complex globallly-managed Cisco wireless network. And I have Little Snitch and firewall etc enabled--many things that could potentially make it difficult.
Anyway, as a customer I am certainly open to any reasonably convenient option that allows me to keep my data under my control, whatever option AgileBits decides to pursue. But PLEASE ensure there is always this option (and it really needs to be at least bidirectional--as far as I could understand the iTunes sync seems to be only one-way, but the beta USB cable sync is bidirectional)
I (and many others I'm sure) are certainly willing to setup our own syncing service on a laptop/home desktop/server/NAS device if necessary. I hope you are considering partnering with some of the major NAS brands like QNAP and Synology that have very extensible platforms to add services. I realize not all users would be willing or able to do this, but for those who aren't, then they can always use the cloud option to keep it simple. There has to be a compromise somewhere.
I know you guys build a very good safe, but I'd rather have it in my house than out on the sidewalk :)
Best regards,
Maged
0 -
This post is getting TLDR but I did not see SSH server being discussed as a storage point for the password archive. That would provide a lot of flexibility for advanced users and enterprise.
0 -
That's a nice idea @trodemaster,
It's fine that you haven't read the entire thread. Nobody actually mentioned SSH before, but the reasons that we don't support such an option has been mentioned.
Let me first elaborate on how I would envision SSH working. With the Agile Keychain Format (where every record is its own file) then using something like rsync over ssh should work (for synching among desktops. (Years ago, I actually did have this working on a test system, but keep in mind that I was a system and network administrator in a previous life, and I'd already been using rsync over ssh to sync other things before Dropbox came along.)
The reason we don't support this is because there is just too much network and server configuration to "get right" for this to work reliably for most people. You, of course, are free to experiment with this on your own for synching Agile Keychain Format data across your desktops where you can configure rsync and ssh.
This may not work as well with the 1Password 4 Cloud Keychain Format data, as multiple items are stored in the same files. rsync can attempt some smart conflict resolution, but I wouldn't want to rely on it.
If you attempt some method which we don't support, please understand that you should be obsessive about backups and that if you get into trouble, we won't be in a position to help you out of it.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
That's right, @jaydisc. I stand corrected.
0 -
Assuming that Dropbox could be compromised […]
You should assume that 1Password is compromised in one way or another. A software like 1Password is without any doubt of high interested to NSA and Co. Canada has been a very close American ally with regard to global surveillance for decades …
0 -
I do assume this. That's the intent of my comment.
0 -
i highly recommend to integrate WUALA (wuala.com) cloud storage to 1password syncing. WUALA is based in Zürich, Swizerland and has very high encryption standards.
0 -
Hi @Chmars,
If you assume that 1Password is compromised, then it doesn't matter if we use Dropbox or whatever. That would be game over. The same is largely true if you assume that your operating system is compromised.
By the way, we have developers in several different countries (CA, US, UK, NL), each with read access to our source code. That doesn't completely rule out us being evil (or compelled to be evil), but it should certainly give you some confidence that if someone tried to compromise 1Password, someone else would say something.
I know that this has been a long thread, @fvng, but with respect to solutions like Wuala, I'd like to refer you to an earlier post. It's hard to keep track of what has already been said, but that would be a good post to review.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Hi Jeffrey, I don't consider AgileBits and you evil but why should you of all software companies be able to resist the legal pressure to fully cooperate with intelligence agencies?
You might not want to cooperate but you have too – and you are not allowed to talk about it … sure, a Prism slide mentioning 1Password would be inconvenient but since surveillance is global and covers all data, it wouldn't really be a competitive disadvantage.
1Password is very convenient but it would be naive to assume that it could offer any protection against surveillance. And there's of course no way you could plausibly deny cooperation with intelligence agencies etc. … that's OK, it's not your fault, but please try at least to make it not too easy – there's legal compliance and there's compliancy.
0 -
It has begun!
Of course I don't really believe that. After all, passwords above 30 characters are just security theater, and you guys don't do security theater (annoying link to some other thread omitted).
0 -
@jpgoldberg wrote in #26:
One of the ways that I got my start in this business was trying to teach smart, motivated people how to use PGP correctly. I was postmaster at a post-graduate technical university in the UK. People did want file and email security and I wanted them to have it as well. Even under these ideal circumstances, my attempts were a failure.
Oh, c’mon. It’s not that hard.
0 -
While you are working on other sync options, why not put Wifi syncing back in, just the way that it was working in version 3, for those many of us who had no problems with it.
You can label it as a temporary and unsupported feature so that you do not have to suffer the support burden caused by problematic network situations, while you work on other options. That would allow all of the people who were successfully using it, in version 3, to upgrade and enjoy the version 4 features and improvements.
This would get you a happier client base, which is usually good for business.
Most of the people that your support staff are talking to, in the forums, about this, will be satisfied which will cut down on your support staff forum load.
0 -
And there's of course no way you could plausibly deny cooperation with intelligence agencies etc. … that's OK, it's not your fault, but please try at least to make it not too easy – there's legal compliance and there's compliancy.
To my knowledge, there has never been an instance of legal pressure to stop anyone from offering true end-to-end encryption. When a company has the capacity to get a users decryption key, then there has been pressure to use that capacity and to turn over that information to governments. But as we never see your keys or your Master Password, we have nothing that we can be compelled to turn over.
Could we be compelled to deliberately weaken 1Password so that we (or someone) can got your Master Password or encryption keys? I really don't think that the laws (or secret court interpretations of the laws) have gotten that bad yet. Even (proposed) requirements that telecoms companions make their equipment easy to tap don't go so far. (The telecoms companies already have your data passing through their systems).
We never see any of your data in any form, we can't be compelled to grant access to what we don't have. I think that this should cover the "don't make it too easy" to turn over data or access.
However, I'm offering one person's opinion on the state of the law. You have to form your own judgement and decide what is the appropriate actions for your security needs.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
The two positions from Agile: 1) A blind assumption that the cloud is secure and 2) forcing users to use it are troubling. We already know dropbox has not been fully truthful about having access to information in accounts. All it takes is a single defect in your code (or in the algorithms, though that's less likely) to be found at some point in the future. That will expose every keychain in the cloud to put every single password from every single user at risk.
Granted, you're getting better on #1, but in that light, why are we still not seeing demonstrable changes in #2?
I sure hope that we have a chance to disable the default sync to cloud before you do it for a couple of reasons. First, once the data's there, we can never be sure that it's been deleted. Second, you may get some of your customer's fired. Most large (and many small and medium) organizations prohibit the use of third-party cloud services to host confidential data, and passwords certainly fall into that category. At the very least, you need a 'would you like to upload your data' dialog prior to doing so.
By the way, does 1P v3 work on iOS 7? If not, USB Sync (or some other offline sync) is a critical path capability.
And just a thought: the new keychain sync in OSX 10.9 is going to be 'good enough' for a lot of people, and is a real threat to Agilebits' bread and butter. Non-cloud sync is a key differentiator that can keep 1Password from getting hit too hard.
0 -
Hi @ihotka,
I am not sure why you think that we assume that the cloud is secure. If we really thought the cloud's secure we wouldn't be encrypting your data with your Master Password. Likewise, we don't think that your hard disk is secure. And so we also encrypt your data there. The whole point of encrypting your data is because we do not believe that the places that the data is stored is "secure".
Perhaps I've misunderstood what you said when you said
The two positions from Agile: 1) A blind assumption that the cloud is secure ...
but I don't see a lot of scope for misreading that. If we made such a blind assumption, we wouldn't be using encryption.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Fair enough, I could have put it better - and blind is probably too strong a word. But I'll still point out that there's three assumptions in what I hear you saying:
There's an assumption that the crypto is secure, that there are no flaws in your implementation of the crypto, and an implied assumption that users choose strong passphrases, so there's little or no additional risk to storing an encrypted keychain in the cloud. Let's look at those assumptions.
1) Crypto is secure. For now, yes, but attacks only get better (and they already have against AES). Granted, if there's a general break against AES we have all sorts of other major issues.
2) Implementation of crypto is flaw free. In the absence of published and/or audited code, there's certainly no way for the public to know, but let's set that aside. The point here is that no matter how good your internal QA processes are, there's a risk that a flaw in the implementation exists (undiscovered) today. It is mathematically impossible to prove that code is clean.
3) There's no way to be sure, but I suspect that most users who find it too difficult to turn on cloud syncing probably don't choose to use strong passphrases (after all, that would be too hard to enter into an iphone). And that's not just an assumption: it's why Agile has previously not fully secured all the data in the iPhone application (some was only protected by a PIN).
Rather than poke at one particular consumer cloud provider, let me note that I don't trust any of them - especially ones that are "free". All it takes is for either 1) a vulnerability in their service, or 2) a malicious employee at that service, and the keychain file is compromised.
Now if I'm an attacker, I realize that those keychains are extremely high value, and very small. So it's a worthwhile target to obtain and store them because 1) I know that attacks only get better, and 2) more bugs are always found. Add in 3) that users probably don't all choose strong passphrases and I might be able to guess some of them right now, and it's a tempting target. (I'm aware that you've implemented measures to make #3 computationally more difficult).
I'll grant your point about physical hard drives - the evil maid, etc. But it's one thing to risk the threat of a single maid having to break into my hotel room (or drive by and break into my house), and it's something completely different to hand out copies of the hard drive to an entire evil maid convention, or post them to evilmaid.com for the entire evil maid population of the world to see. The threat is massively multiplied by putting sensitive data into a consumer grade cloud system.
Sure, this is low probability, but it's a catastrophic impact if it does happen. Probability * impact = threat. It can be almost completely mitigated by maintaining physical control over the keychain file. Using device level encryption in addition to the keychain encryption essentially takes the probability to zero.
For me, most corporate employees, and many of your users (judging by the number of forum posts, both here and elsewhere), the slight advantage in syncing ease isn't worth accepting that level of threat. Of all the data that I'm not going to trust to the cloud, it's the keys to the kingdom!
So I'm arguing three things:
1) That the default should be to not sync to the cloud. Users should accept that risk for themselves, rather than you accepting it for them. At the very least, it should have that dialog asking what to do. Again I go back to my point that users who find it too difficult to turn on, are probably choosing poor passwords (not passphrases), and are exactly the ones who are at the highest risk of compromise.
2) That a non-cloud sync solution should be a higher priority than it appears to be. Wi-Fi sync has been working fine for years, but I'll grant that for some users (again the ones in that bucket above) it's probably too difficult to configure. USB sync is a good option too, or AirDrop in iOS7 might work as well. And for folks in many corporate or government environments, it's mandatory. In a strange way, 1P v3 is now more secure than 1P v4 :-).
3) That with Apple offering a cloud-sync solution, it's likely to be good enough for a large chunk of users (again, probably the ones who find it too difficult to turn on cloud sync), and they will probably migrate to it. 1Password has an opportunity here to shift it's marketing both towards "Ease" (works in multiple browsers and platforms), and towards "more secure" (we let you decide where your data lives) to counteract the customer loss. But to do that, #1 and #2 have to be in place.
0 -
Putting data in the cloud is insecure. Putting passwords to all your accounts in the cloud is not safe. Dropbox policy on deletions is that they will try but don't guarantee your data will ever be deleted from their servers. Along with the news that Dropbox itself was part of the NSA's program. Now we have this quote from LavaBits Founder.
"This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would strongly recommend against anyone trusting their private data to a company with physical ties to the United States,"
Considering all of this will you bring back WiFi Sync? Local Network Sync? Some way of storing and syncing our data that requires a judge to issue a warrant, and law enforcement to execute that warrant, with our full knowledge, instead of shoving DropBox down our throat? Please?
0 -
Thank you, @ihotka. Those are all very fair points.
I'm going to quibble a bit about your use of the word "assume". For example, I would replace your statement that we assume that the crypto is secure with a statement saying that the security of your data with 1Password depends on the ultimate security of the crypto. The reason that I prefer the second wording is that it acknowledges that we are fully aware of this and we pay attention to this fact.
The same goes for the other two assumptions. Obviously the security of the system depends on what kinds of bugs or design flaws might be in 1Password. Just as obviously, we are fully aware of this. And anyone who claims that their software is completely bug free should not be in the business to providing software to people. So we are not "assuming" such a mythical state, and we are acutely aware that your data security depends on us doing things right.
But what keeps me awake at night is your third assumption. People not using good Master Passwords. We have zero data on what people do. I just got back from a PasswordsCon, where in one of my talks, I spoke specifically about this issue. We have to make it easier for people to use strong Master Passwords.
I also mentioned that it would be really nice if we could reduce the chances that people's encrypted data is captured. And this is the area where we disagree. I don't think we disagree on fundamentals, but instead of the relative risks. You see "the cloud" as a far riskier place for this kind of data than individuals' own devices. It comes down to threat models.
It is actually very very difficult to judge these models because there just isn't enough data. We don't know what typically happens to the data on disks of stolen computers. Do these just get wiped and resold, or is there a black market that gets that kind of data into the hands of people who might have the means and incentives to attack it? Don't know.
On the Cloud side it is even more complicated. Leaving governments aside for the moment (I will get back there) I would think that to date people's data has been safer from capture from attackers there than on their own devices. As you very correctly point out, individual computers get stolen one at a time, but a single breach of a cloud service could affect all users at once. Because such catastrophic breaches have been rare, we have no basis to judge how likely they are.
Of course there could be large scale collection of 1Password data without a cloud breach. Had Devil Robber 3 spread more successfully, then large numbers of people would have had their 1Password data stolen off of their hard disks via malware. So the threat of catastrophic capture isn't limited to the cloud.
Anyway, it is exactly because there is so much uncertainty in even trying to compare relative risks, that I have to be skeptical of my own judgements. Sure, I have a strong intuition that people's concerns about data capture from the cloud is disproportionate. But I have to acknowledge that I don't have clear data to back up my intuition.
Finally, there is the governmental capture of your data. We should always assume that the data stored on some service is available to governments through subpoenas of one sort or another. As I said much much earlier, I don't think that PRISM changes that concern. If the government wants your data off of some service it can get it. This is not in any way new. There is a great deal to be concerned about with respect to what we've been learning about how the NSA operates and what it is collecting, but with respect to 1Password security there is nothing new.
If the NSA or FBI (or the equivalent around the world) really want a copy of your data, they are going to get it. Whether they get it from a cloud service or by compromising your own system or through some mechanism that we haven't thought of, they will get it. The only way to avoid that is to go to extremes in operational security. Quite frankly, if your threat model realistically involves such threats, what are you doing running an operating system that you didn't compile yourself?
This is not to say that we don't try to make 1Password as strong as we can. Anyone, governmental or otherwise, attempting to find your secrets in 1Password without your willing consent is an attacker. We can't in our design think in terms of governmental versus non-governmental attackers. An attacker is an attacker is an attacker.
But because 1Password operates in an environment that doesn't reach the very highest levels of security (in operates on everyday devices with everyday operating systems) we have very limited ability to ensure that your encrypted data doesn't get captured somehow. We are not in the secure operating system business.
So what I ask is that when you consider the risk of data capture by an attacker, you focus on more than just "the cloud". It is extremely useful to think about the risks posed by data capture, but I think it is a mistake to focus all of that attention on just one way that such capture can occur. Again, this is where we probably disagree. But I will still ask you again to put the cloud in perspective with other lines of attack.
As for our security priorities, what you see now reflects what our priorities have been. These things take time. It may be a while before current security priorities become visible. We aren't in the vaporware business, so I am not going to say anything about which approaches are getting the most attention. What I can say is that our desire for people to be able to have more control over their data isn't new. It's just a question of getting that all to work while still making 1Password something that makes behaving securely easy instead of a chore.
Today's news about news about Lavabit and Silent Circle Mail is a warning to anyone who tries to implement a zero-knowledge (service operators have no information about what users are doing) end-to-end encrypted (only you have the capability to decrypt your data) solution.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0
