PRISM and cloud syncing security

12346»

Comments

  • Of course, I didn't mean you personally. I don't know everything you've said on here. I'm not stalking you that closely. ;)
    I meant you "Agilebits". I could only assume that the big delay in getting non-dropbox options available is because there are issues with one of your supported platforms.
    So the question is, why can we not get GoogleDrive on Android and of course we can use it on Windows too?

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    There are lots of things that are attractive about Transporter, as @John Young‌ mentioned. I should note that their overall privacy model isn't very different than Dropbox's. Technically it is very different, but the people who run the Transporter system do, as I understand it, have the capability of reading whatever you store on your own Transporter device. I see no reason to expect them to be less "cooperative" with or vulnerable to intelligence agencies than Dropbox is.

    So if we got this running, it would be an alternative to Dropbox, but I'm not at all sure that it provides more privacy than Dropbox.

  • When a user first sets up synching, do we really want to present them with a list that says something like. "If you ever plan to use 1Password on iOS then don't use Bittorrent; if you ever plan to use 1Password on Windows, but not mobile, than CronoSync is fine, but not SugarSync ..."

    New users wouldn't have to make that decision up front. As you said, the sync mechanism is not directly tied to the 1Password data format so I can start out using Bittorrent to sync me PC and Mac together. If I later get an iOS device then I can re-visit the support list and choose a different sync service that offers the compatibility that I now need. The services are mostly all free so switching between them is no great headache.

    My point is that lack of support one some platforms is not a reason to not support a service on other platforms. Granted, there will be a cost/benefit calculation to be made somewhere on whether the user base is there to make the development effort worthwhile. GoogleDrive on it's own has that demand I think, and over all people clearly want to drop Dropbox so even if GoogleDrive is not fully supported on iOS, it would be worth providing just to give Android users an iCloud analogue.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    No worries @RichardPayne‌!

    I didn't take it as an accusation, and I have very frequently touted the benefits of something that works across platforms, so it is a shoe fits and I will gladly wear it.

    I do like your example of GoogleDrive. That would work across desktops and Android. But again, I should point out that GoogleDrive is no improvement to Dropbox with respect to your privacy. This isn't a reason for us to shun it, but it doesn't provide its own layer of PRISM resistance that people seek. I really do love Google, but it isn't exactly the first company that I think of as protecting the privacy of the data that I might hand to it. But whatever their attitudes toward data privacy are, both are in the identical position with respect to PRISM and PRISM-like attacks.

    This is why end-to-end encryption is so important. With end-to-end, the service providers have nothing meaningful (beyond traffic data) that can be stolen from them, coerced out of them, or abused by them.

    And if someone can achieve provable end-to-end encryption (not easy to do) then your data remains safe even if the ghost of J. Edger Hoover joins the board of the company running such a service.

  • @jpgoldberg‌ I do completely agree with you on the security aspect. Anyone thinks that they are any less safe with Rice on the dropbox board is a naive fool.

    However, there's two other, far more important, points here (mentioned by others already):

    1) The consumer choice aspect. At present, Android users have exactly one sync choice. Ie none.

    2) Agilebits' business continuity. You are, at present, utterly reliant on Dropbox for a platform that is nearly 50% of the market. If Dropbox became unusable for whatever reason then you'd be in trouble.

  • khadkhad Social Choreographer

    Team Member

    Both are valid concerns and factor in to the reasons we are pursuing other sync solutions as well. :)

  • 1password for Android allows us to set up sync using local files or using Dropbox.
    Some (probably really paranoid) people have thoughts about security if they store their whole bunch of passwords inside a cloud-service without taking additional care about encryption even if the keychain itself is already encrypted.
    Something like "I know it's encrypted, because I encrypted it and not only because 1password says it could be encrypted". It's not a matter of trust in 1password, but a matter of being suspicious about servers within the USA (means NSA has access) which are responsible for syncing my keychain.

    One of that services allowing us to encrypt files especially for cloud-services is Boxcyptor (https://www.boxcryptor.com/). Of course you can also set up a sync service like rsync on your own server to have it much more secure.
    But to have it easy, let's only talk about Boxcryptor.

    Boxcryptor encrypts files end-to-end before storing them inside dropbox
    here's an example for the Boxcryptor-System:
    image
    And here's a simple text-file viewed without boxcryptor and (of course censored) with boxcryptor-decryption in plaintext:
    image

    so Boxcryptor encrypts files within Drobox (or other cloud services) before letting the original cloud-services sync that files so that even drobox never knows what you're actually really syncing.
    In case of an possible access by the NSA Drobox has the encrpyted files and the NSA (probably - hoping not) only knows how to decrypt the 1password-encryption but can't apply that to the files stored in Drobox because of the additional encryption we took care about.

    Boxcryptor has also an Android-App (and an iOS-App) which allows us to authenticate for decypting files on our smartphones. Of course the original Drobox app can't really access these files, or it can only read that files in the boxcryptor-encrypted-state.

    And here's the only point I don't know - It should be possible to use the boxcyptor-app to access and decrypt the encrypted keychain-files within dropbox before using that for reading the data stored in the keychain with our master-passwords. But for now I only found an option to decrypt single files with the boxcryptor-android-app and not whole portable programs like it's possible with the windows or mac-client of boxcryptor.

    So it's not a problem of the desktop-clients of 1password - because there you can direct it to the storage which will be decrypted on-the-fly while 1password accesses these files, but only a problem of using 2 android-apps combined with each other to manage the sync.

    It would be nice to have an option to use keychains where the owner can self-encrypt it externally or especially for syncing.
    I had thoughts about using 1password only with keychains stored inside truecrypt-containers (because I know truecrypt-containers are encrypted in a way I know how it's encrypted), but the truecrypt-way of encryption is too unflexible to sync between devices - so Boxcryptor is the best to have synced files encrypted.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hi @paradonym‌!

    I've merged your excellent posting into our long running discussion of PRISM and cloud synching security. This helps consolidate this discussion into one place (so people can see each others comments and also see our comments as well).

    A brief recap is

    1. On June 7, 2013 we posted an article On the NSA, PRISM, and what it means for your 1Password data

    2. We created this discussion thread.

    3. Posted a message here that roughly says that the answer to "Have you thought of X?" is almost always "yes".

      Although that message is dated, it still is what I'm going to ask you to look at now. That particularly posting is nearly a year old now, so let me point out that some things have changed since then.

      • We've reintroduced WiFi sync for some platforms
      • We've introduced Folder Sync on Mac
      • Brought the opvault (1Password 4 sync format) to more platforms
    4. Responded on September 6 to the September 5 revelations that the NSA has been weakening cryptographic standards and tools.

    5. Acknowledged that it continues to be a long wait for those wishing to move entirely away from Dropbox for all 1Password platforms.

      For something to entirely replace Dropbox for us, it needs to be built into 1Password on the mobile platforms, and therefore requires a good stable SDK. (See that early "required reading" post). While these exist for things like GDrive and SkyDrive, those have security architectures identical to Dropbox's, and so do not seem like a particularly useful place for us to put our efforts.

      Partial replacements are already available. Folder Sync will work across desktops, iCloud sync will work among iOS and OS X.

    Now this recap doesn't do justice to the more than 150 posts in this discussion. But it at least gives you some sense of what has been going on, particularly since one would have to be insane to go back and read all of them. (Though you may wish to search for mentions of boxcryptor.)

  • @paradonym‌

    Something like "I know it's encrypted, because I encrypted it and not only because 1password says it could be encrypted".

    You never encrypt anything yourself. Unless you are doing the encryption manually or you skilled enough read and verify the source code of the software you are using then you must trust someone.

    It's not a matter of trust in 1password, but a matter of being suspicious about servers within the USA (means NSA has access) which are responsible for syncing my keychain.

    What makes you think the NSA don't have access to servers outside the USA?

    @jpgoldberg‌ is using boxcrypter on top already encrypted 1password data effectively double encryption. I recall you writing that this adds liitle meaningful security and can be counterproductive as it may produce observable and exploitable patterns in the cipher text. Is that correct?

  • paradonymparadonym
    edited April 2014

    --You never encrypt anything yourself.

    But it's a difference if a company says "It's closed source - but it's secure" or thousands of other people say "I viewed the source - should be secure" - okay - heartbleed told us something different... That's a point. And if the NSA has a backdoor already programmed for the service (because they submit many of that encryption-stuff to openSource-projects) its also another point

    --What makes you think the NSA don't have access to servers outside the USA?

    The NSA has access to servers outside the USA, they publicly said that (in a roundabout way)... But then an encryption has to be client-side - so that the sync server doesn't know what you're currently using or on which way it's really encrypted. And if it's a protocol only used for syncing the NSA can't know that this service is only used to sync keychains...
    Everything is exploitable - and I guess the NSA is the biggest and fastest player in searching exploits (for their own use). so making encryptions where finding exploits is really hard (for the whole power of all the internet-servers out there) should be the key...
    But a little bit more security should be better - and getting other encrypted data out of decrypted files is something I guess nobody expects when he's really hacking stuff.

  • That's a point. And if the NSA has a backdoor already programmed for the service (because they submit many of that encryption-stuff to openSource-projects) its also another point

    I don't see how using a point-to-point encrypted sync service would help here. If you're concern that NSA may surreptitiously compromise Agilebits then there are far easier ways to do it than to weaken the AES encryption scheme. They would simply backdoor the software to steal your entire login set.

    Everything is exploitable - and I guess the NSA is the biggest and fastest player in searching exploits (for their own use). so making encryptions where finding exploits is really hard (for the whole power of all the internet-servers out there) should be the key

    This is already the case just using the AES scheme that 1Password uses. Have a read through some of the blogs here to understand there time scales involved in cracking a master password.
    While a split key arrangement would slightly increase security, I would submit that that level of security is unnecessary for most people. The effort involved in the NSA compromising your systems would simply not be worth it. If you feel that your data is of a high enough value that it might be at risk of dedicated NSA attention then you really shouldn't be using any sync service, even an encrypted one. You should probably also be spending a significant amount of money on physical security. Oh, and compiling your own copy of an open source OS having carefully inspected the source.

    The risk of key splitting using a physical device to provide the second key half is that of losing the device. It's the same as if you forget your master password, but losing a device (or having it damaged) is much much easier to do. This increases the risk of losing your data massively and I think that for most people, including all of 1Password's users, this risk is not worth it for the small increase in security against remote cracking attempts.
    Now, I'm not saying that it should never be an option, but frankly there's more important and useful things that Agilebits should be prioritising in there development plan.

  • What do you guys think about SpiderOak?

  • khadkhad Social Choreographer

    Team Member

    Good question, @Qwik! It falls under (2) in Jeff's post #9, but we'd love to follow up if you have more specific questions. Depending on the nature of them, they may be best posed in a new thread, but we'll answer them no matter where you post them. :)

12346»
This discussion has been closed.