PRISM and cloud syncing security
Comments
-
Fair enough on the assumption language. It's a disagreement on threat models, but it does reflect that your threat model influences your design choices, and limits our ability to respond to our own models with different levels of security. I understand that the defaults need be easy - I'm just asking that the defaults not the the ONLY way to do things. And let me acknowledge, that for many of your users, syncing to the cloud is better than the alternative (using the same password everywhere), but for others (the ones who wouldn't do that to begin with), we have a different tradeoff we need/want to make.
And yep, we definitely disagree on the relative risk of local versus consumer cloud security. Between physical security, FDE, remote wipe, and other precautions, in my model, local is more secure.
To help show why, let me make sure that I clearly separate consumer grade cloud services from commercial grade services. The latter, at the very least, will have contractual consequences should a breach occur, usually include audits and penetration testing, as well as full disclosure clauses, all of which go a long way towards motivating providers to adopt better security practices. Consumer grade services that offer unalterable click-through agreements (especially the free ones) generally disclaim any liability, which in turn, greatly reduces motivation to to the right things.
So with that, regarding cloud breaches - the fact that we don't have data (which I agree with), doesn't necessarily mean that they are rare - it means that we just don't know how frequent they are. I think we can both agree that there have been incidents that have not been reported, particularly if it was a malicious insider. Which is why I assume that those types of services aren't secure, and won't until I have data to show that they are. I have data about my local machine, so I know it's (relatively) secure. I have little or no data about consumer cloud services, so I assume that they aren't. The one data point I do have, that one of the most popular consumer cloud services mislead users about their own ability to access user data, doesn't exactly increase my trust level.
Point taken on targeted malware against local machines - have to think more about that one actually :-). And point completely granted on nation-state level threats. Unless you're running offline, in a faraday cage to block TEMPEST, with (as you say) an OS you compiled (and audited) yourself, with physical security, etc, etc, etc they're going to have your data. If there's anyone out there that's made a general break (or is likely to make one) against AES, it's the three-letter-agencies (and that would explain some of the large data center construction that's been reported - storing for a future breakthrough). I saw the first article, but hadn't seen the silent circle post. If Phil and company are concerned about that threat, well, "wow" I guess is the only response.
I appreciate the challenge you have - if it's hard to be secure, then folks won't do it (back to the secure passphrase insomnia). But please remeember, your users do have different threat models (and corporate policies we have to comply with), so please make design choices that give us the flexibility to meet those needs and to make that tradeoff ourselves, rather than having it imposed via design limitations. For example, the lack of universal master password authentication for all data in the iPhone application (versus a painful per-item basis) is a design choice that made it hard to be secure. Likewise, having the application sync to iCloud without first giving us the opportunity to turn it off would be another. Maybe turn it on by default, but don't do anything until after confirmation.
Having 'read between the lines', I think I understand. Patience is a virtue :-). With that though, do you know if 1P3 works on iOS7? I'm presuming it does, so barring an unpatched security flaw in it, that buys us time until the revised priorities become visible.
Thanks for the open exchange - it's much appreciated.
0 -
Thanks again!
Patience is a virtue, and I wish I could say that it will pay off "soon". But getting these things right isn't easy. The fate of Lavabit also raises questions about whether we can rely on even zero-knowledge sync solutions. And so we really do need to offer a solution for those who do want complete control of their data at every point. Whether that will be a restoration of something like WiFi sync or some other locally manageable mechanism remains to be seen. And how we reconcile this with our aversion to having an "expert mode" (we want 1Password to work great for everyone, especially for non-experts) is also something we need to address.
I fully acknowledge your points for why your risk assessment is as it is. I think I've been reacting to what I've seen as anti-cloud hysteria, which is why I've been calling on people to consider the relative risks. You clearly have considered the relative risks, and your concerns are certainly not hysterical. So I apologize for reacting to what I imagined your position to be instead of to fully considering what you've been saying.
Our NDA with Apple gives us limited scope to talk about what does and doesn't run on developer previews. But we have no reason to believe that wifi be any difficulty in 1P3 on iOS continuing to work with wifi synching. Note however, that 1Password 3 on iOS will stop working with Dropbox on September 1.
All I can really say is that we are not going to abandon people who want full control over their 1Password data throughout the sync process. But when and how we offer you a solution is just not something I can talk about.
Cheers, and thanks for a great conversation.
-j
0 -
@ucs308, I merged your post with this existing thread. I know it's a lot to read, but you can get the gist of it by reading our blog post "On the NSA, PRISM, and what it means for your 1Password data" as well as Jeff's post #9 on page 1 of this thread. Please let us know if you still have any further questions or concerns. We are always here to help.
@lhotka, I would also add to what Jeff wrote that 1Password 4 for iOS is already compatible with iOS 7. We posted about it on our blog a month or so ago. :)
0 -
I use 1Password for ~all my non-to-semi sensitive passwords, and they're all in one place, so an attack on it would be a serious threat for me. I have a few Macs, a PC (which I don't sync), and an iPhone and iPad. I last synced them when you last supported wifi sync. :( I'm pretty familiar with Dropbox's internal security, which is why I've always been unwilling to put anything sensitive there. While the 1Password db is encrypted, it's encrypted with a "reasonable" master passphrase, one which I routinely enter on a keyboard. It would be fairly easy to compromise with a keylogger, video camera, or any of several other means. A lot of my security is built around keeping my password db (encrypted) relatively safe, on top of the passphrase.
One thing I'd like you to add ASAP is the "local-only key file" -- essentially a separate key which gets mixed with the key derived from passphrase to encrypt the password db. LastPass does this, and it's almost enough to make me switch. This protects people from the "weak master password" problem, at least if the attacker only has access to the password db itself (at a cloud provider, say -- like if you leave iCloud syncing as a default). You could be even better by protecting the "local-only key file" with Apple's iOS data protection APIs, although doing this on OSX too would be harder. You arguably should have a per-device "local only key file", a global master password, and your encrypted password db should basically use one of the keys generated from global passphrase and any one of those device-specific keys to decrypt the password db. That way, the local key file never needs to leave any given device, and new devices can be added or removed from the password db at any time. (sorry for not explaining this more clearly, it's 0400, and it's a pretty standard thing).
It's pretty clear that an AgileBits hosted sync service would be a security liability -- if someone wanted to pressure you to backdoor the client, having you operate the sync service wouldn't be very good at all -- there would be no improvement in security vs. dropbox in practice, and it might even make it a more tempting target since it would involve only one company vs. two (unless it were a backdoor which "phoned home" with the target info directly). You also don't really seem like an "online services" company, so I'd be a bit concerned about availability and other things like that. Probably not worth it. I'm worried about "mistakes" in 1Password, intentionally-added (under duress or court order) or otherwise, since I don't audit the source code of every release before installing it. The host OS and general ecosystem is even more of a vulnerability, but 1Password is just such a tempting target. If they're just benign errors, keeping my password db as far away from AgileBits control as possible protects me somewhat. I'm planning to do crazy iOS 7 per-app VPNing and filtering on my side, too.
Since you have full control over your client and keychain format, I'd probably try to come up with a storage format which works with some kind of existing sync technology. WebDAV is one obvious option (which has some history for you) -- IMAP might be another (it's how Apple does notes, and ~everyone has IMAP servers and access now). You could use "newest message with a given ID" to update the local db. Everything encrypted, obviously. Wi Fi sync is certainly better than what you have right now, but I'd really like to be able to sync (over a VPN, and using an encrypted sync system) between my iPhone out in the field and my "server" (either a real server I control or a mac at home) -- knowing a password is actually backed up as soon as I create it makes me a lot more willing to use long random generated strings every time. The ideal is never having anything on just one device. Wi Fi sync actually worked pretty well for me.
So, if you want it to work for "normal" users, the ideal is figuring out how to make your interchange format work with an existing network service which can either be self-hosted by power users or subscribed to by a regular users, a service which isn't 1Password specific, or even security specific. Dropbox fails because there's no "open" Dropbox I can host myself.
(In the long run, I'm thinking a host-computer hosted password manager is the wrong solution for anything requiring real security. I'd be more comfortable with a delegated password and authentication manager which lived on a smartcard or small/cheap HSM, and just handled auth on my behalf, without letting me get the original keys (at least, in normal operation -- it's probably not going to be robust enough to have no admin override ever needed, but it doesn't need to be done with a passphrase one could easily capture, might require physical access to the device and a different input method, etc. But at that point you just do some kind of PK or hash based authentication rather than passwords to sites which support it, too. But this is all in the future.)
I don't think Lavabit and Silent Mail are particularly good examples of great zero-knowledge systems, though -- Lavabit essentially shut down due to not having enough money for real lawyers, and Silent Circle wanted to kill Silent Mail because it was ~1% of their commercial value and ~99% of their risk, and put their other products at risk. A reasonably well resourced provider defending their core product could probably go a bit harder v NSA than either did.
0 -
As I understand it, the 1Password Cloud Keychain is only used for data residing on iCloud (on Mac, that would be: ~/Library/Mobile Documents), while all clients (1Password 4 on Mac and iOS) actually work with data locally stored inside an sqlite3 database which is kept in sync with whatever is on iCloud. Data on iCloud is basically a full copy (but in different format) of the local data stored in the clients. Have you ever thought of using iCloud just as a sort of "message passing system", where you only store whatever data was updated on a client so that it propagates to all other devices; then when all devices have "consumed" these updates, the last one would remove it. WIth this kind of mechanism, the iCloud data store would be empty for most of the time, and only store whatever data has been updated for the time needed for all devices to synchronize (obviously, if one of the devices is seldom used or 1P is seldom launched on it, data would stay on iCloud for longer). I imagine there would also need to be a way to "register" a new device, so that it can receive the full database once (from one of the clients of choice; it would download it and then remove it) and from then on it would just get the updates like all other registered devices. Does this make sense at all? Have you ever thought of something like that?
Thanks for the long thread, it's been a very interesting read up to now :-)
0 -
Hi @rdl,
Thanks for your suggestions. Please do take a look at one of the earlier comments in this discussion where I have a brief outline of these and other approaches.
From a cryptographic point of view, I personally find key splitting the a very attractive option. It is like your "local key file" suggestion, but involves two key files: one which is synced and one which stays fully local. Both are needed to decrypt.
However elegant that is from a cryptographic point of view, it probably is not something that we can get to work. People will need to get the "local" key file onto each device on which they use 1Password. Loss or corruption of that local key would be catastrophic. (If we do it right, and we would do it right, there would be no way to unlock the 1Password data without it.) So the risk to data availability becomes very large.
We are also exploring other approaches which you've suggested. I do realize that this has been a long discussion, and I can't blame anyone for not reading all of it, but please do look at that post number 9 and recognize that many of the things mentioned there have been elaborated in later discussion.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
Hi @wifisyncer,
In general the answer to the question of "have you ever though of X" is almost always "yes".
Before we developed the Agile Keychain Format we looked extensively at such approaches. The security gain would be limited (but real) in that an attacker who had historical access to the sync server would still be able to get everything. But it would prevent the attacker who got one time access with no history. So there would be a security gain, but not as much as people may imagine.
But the cost in reliability of syncing grows dramatically. Because data loss or data corruption would be so damaging to people using 1Password, we want an extremely robust synching system. To date, we don't think that the limited gain from your proposal is worth the other risks. But this still remains an idea that we have in our minds.
So thanks for the suggestion. I'm pleased that I had an opportunity to talk about that.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com0 -
I understand completely - good luck with your design dilemma. I'll stick with rev 3 for a while - we've got wi-fi working reliably, so barring any security related reasons to move, we're good until the future happens.
Cheers
0 -
Interesting observation by Jon Callas drawing a connection between the shutdown of Silent Mail and the security / usability issues that are at the heart of much of the discussion in threads like this one.
Over the years, I've become a radical on usability. I believe that usability is all. It's easy to forget it now, but PGP was a triumph because you didn't have to be a cryptographer, you only had to be a techie. We progressed PGP so that you could be non-technical and get by, and then we created PGP Universal which was designed to allow complete ease of use with a trusted staff. That trusted staff was the fly in the ointment of Silent Mail and the crux of why we shut it down -- we created it because of usability concerns and killed it because of security concerns. Things that were okay ideas in May 2013 were suddenly not good ideas in August. I'm sure you've noted when using our service our belief in usability. Without usability that is similar to the non-secure equivalent, we are nothing because the users will just not be secure.
There's lots more in the link on the subject of trust (and lack thereof) as it relates to security.
0 -
Usable, really secure email, is the holy grail. Silent Circle's email system wasn't really up to the kinds of security that people hoped for. I think that their decision to stop it was to avoid being a vulnerable place where people might think they had full security.
It's Lavabit where the really scary stuff is. Of course we don't know what was asked of Lavabit, but given that Lavabit system really did look like they would have no valuable information to turn over to anyone, that the request was to actually modify their system in a way that allowed for the capture of valuable data. Of course we can only speculate that this is what happened, but it is naturally something that I find terrifying.
The uncertainty surrounding that has put everyone who is in the business of providing people with genuine end-to-end encryption on edge. Within the community, there has been a sense that as long as you design systems so that you don't have the capacity acquire any information that the spies would want then you are safe from being compelled to do anything nasty. I still think that this is true, but I am no longer as certain as I once was.
0 -
Just an update to our previous conversation: http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/
1Password can protect against that for the sites it creates PW's for (assuming that the company allows you to use long, random passphrases, and doesn't offer reset questions with answers that users make available on social media).
But, I noticed that 1Password is in the list of targets. So now the challenge is to make sure that the keys to the kingdom are secure.
We're back to your 'keep you up at night' comment about creating secure passphrases. For folks who store PW's in the cloud, it's absolutely critical that they choose a truly strong (versus apparently strong) passphrase. I wonder just how many folks do that? Password entropy is a tough thing to calculate, but that'd be a nice feature for an upcoming version. Maybe even warn users against storing keychains with weak passphrases in the cloud?
It's probably only a matter of a handful of years when the dictionary attacks are so good that it's nearly impossible for normal users to create a secure password. In the war of artillery and armour, artillery usually wins in the end. Biometrics aren't the answer (how hard is it to change your retina or fingerprint when it's stolen?), so we might be looking at some sort of physical cryptographic device - and one for each site. But SecureID was compromised, so maybe that's not an option either. Ugh. Site-specific, device-specific certificate pairs? Double Ugh.
It's going to be a very interesting ride.
0 -
Hi, @Ihotka. I should probably move your post to a different thread discussing defenses against password crackers, but it will be quicker for me to just point you to a blog post from April, back when hashcat first displayed its 1Password tools.
I'm pretty sure we have a few discussion threads on Master Passwords, but I'll have to look.
0 -
As a - late - response on your today re-tweet of http://blog.agilebits.com/2013/06/07/nsa-prism-1password-security/ let me kindly ask again for:
- WLAN sync
- WebDAV support
- Other sync techniques (SFTP, FTPS, SCP, RSYNC via SSH)
Please don not force your users to use Dropbox or iCloud and please do not force me to use cable again.
0 -
Sven, I realize this is a long thread, and I don't expect you to read all of it, but this was discussed on page one. :)
Regarding WebDAV, et al:
http://discussions.agilebits.com/discussion/comment/72325/#Comment_72325
Regarding Wi-Fi syncing:
Please let us know if there is anything else we can help with.
0 -
@jpgoldberg wrote:
It's Lavabit where the really scary stuff is. Of course we don't know what was asked of Lavabit, but given that Lavabit system really did look like they would have no valuable information to turn over to anyone, that the request was to actually modify their system in a way that allowed for the capture of valuable data. Of course we can only speculate that this is what happened, but it is naturally something that I find terrifying.
I recall reading somewhere that Lavabit cooperated earlier this year when it was served with a subpoena relating to a suspect in a child pornography investigation who was using a lavabit email address. Which leads one to imagine that something about the Snowden case may have been different.
The news keeps getting scarier and scarier.
0 -
Khad, even though they've been discussed, I hope you guys are keeping count of all ofthe requests for network protocols that would work over a WAN, e.g. WebDAV and SFTP/SSH. I hope you haven't given up on these due to previous WebDAV issues or your current wifi implementation. Many of us want cloud based syncing, we just want to do it on our own infrastructure.
0 -
Hi @Jaydisc,
We aren't tracking numbers of such requests, but we are definitely noting the enormous demand for that. As usual, I can't reveal exactly where our most active exploration is. You might see some shorter term options coming soon while other things are further ahead. Quite frankly we are pursuing a number of approaches. But we don't promise anything until it is delivered (or, perhaps, visible in a public beta).
0 -
One thing your blog posts doesn't address is whether or not the NSA has contacted you to provide backdoors. Have you considered a Warrant Canary? http://www.rsync.net/resources/notices/canary.txt
0 -
I don't think there's another supplier that I'd prefer to see one of these from more than Agile Bits. Please consider this, guys.
0 -
I very much like the idea of a warrant canary, and so I could imagine that we might set something like that up. But I think that these are less effective than people may hope. There is the assumption behind them that a gag order couldn't prevent the canceling of the announcements. If a (secret) court would uphold the gag order, it seems it would rule that ceasing the announcements would be taken as a violation of the gag.
It's specifically because the informational purpose ceasing the announcement is to communicate, as it would, that an order had been received, that I think courts would not rule favorably. Under normal circumstances "not making a statement" is not a statement. But these things are designed so that "not making a statement" is a statement. So exploring this hasn't been a high priority. Those who are participating in the 1P4 for Mac Beta know that we are busy with lots of other things.
However, if anyone is aware of legal arguments and discussions about this, especially with respect to Canadian law, please, please point me toward that. And once we have a chance to catch our breath, we can see about setting this up.
0 -
As a long time 1P user on multiple devices I was quite happy when dropbox was introduced. I am now starting to migrate off dropbox and on to The Transporter. With their v2 the usage mode for clients is just like dropbox (i.e. 'magic folder') I would just like to add my vote for Transporter support in V4 if possible.
Thanks0 -
Thanks, @phideaux. Noted.
0 -
There are several common cloud storage options now. Is each so unique that supporting more of them, like Sky Drive, Box, Google Drive, etc. would be a problem? Superficially, those all have a fold on the desktop that is automatically synced to the cloud solution. (This is in no way intended to be a criticism of Dropbox, which is my preferred option, even though I have access to quite a lot more capacity elsewhere.)
0 -
Hi @hawkmoth,
This has been a long discussion, and I can't imagine that everyone has read everything, but take a look at message #9 from on the first page for a sort of general overview.
Solutions that work like Dropbox (eg, G-Drive, SkyDrive) should not be difficult to support. We would need to include their SDKs on iOS and Android, so there might be difficulties we wouldn't know about until we really tried to deliver such compatibility. From a privacy perspective, none of those offer any advantage to Dropbox, and so it's not clear whether the additional complexity of adding them as options would be worth it.
Transporter, as @phideaux suggests, looks promising but doesn't (yet) offer an SDK that do what we need on mobile platforms.
If you go back to that early posting, where I described the variety of approaches we could take, keep in mind that we are exploring several. Just because we're (re-)introducing WiFi sync doesn't mean we are stopping there. But as usual, I'm not going to hint at what we are looking at until we are absolutely certain we can deliver it.
0 -
@jpgoldberg, Thanks for the pointer. I do confess not checking the rest of this thread, and I joined the forum sometime along about when I entered the Mac beta test, somewhere around b40 or so, I think.
0 -
@hawkmoth, if you had confessed to having read the entire thread, I would be searching for a gentle way to recommend psychiatric help.
0 -
I very much like the idea of a warrant canary, and so I could imagine that we might set something like that up. But I think that these are less effective than people may hope. There is the assumption behind them that a gag order couldn't prevent the canceling of the announcements. If a (secret) court would uphold the gag order, it seems it would rule that ceasing the announcements would be taken as a violation of the gag.
Maybe when asked if you have been asked to put a backdoor in 1Password you could simply say "You might very well think that; I couldn't possibly comment" and we would all know what you mean, it seemed to work OK in the House of Cards! :-) http://en.wikipedia.org/wiki/Francis_Urquhart (unfortunately I don't think it would be very good for business though).
0 -
Maybe when asked if you have been asked to put a backdoor in 1Password you could simply say "You might very well think that; I couldn't possibly comment" and we would all know what you mean, it seemed to work OK in the House of Cards!
That is brilliant, @macgabe. And I absolutely loved that series. (I haven't see the remake; does it too use that line.)
0 -
More on Warrant Canaries
Although I am skeptical of the actual efficacy of Warrant Canaries (as stated above), I've been having an informal conversation with one of our developers about the NSA and various defenses. Anyway, from this conversation, I can see a benefit of a Warrant Canary. Even if they entirely fail at their stated purpose, they bring public attention to the laws and practices of gag orders. And the more aware that the public is of this sort of thing, the less useful of a tool the gag orders may become.
Anyway, I'm more positively inclined to Warrant Canaries as a result of that discussion than I was a week ago, but it's not something under very active consideration at this point, mostly because of simple priorities. One thing that I've been studying is how we can protect ourselves from potentially malicious random number generators.
0 -
I haven't see the remake; does it too use that line
Yes, Kevin Spacey delivers it very well !
0
