1

My current setup

currently I'm using Boxcryptor Classic 1.x (still compatible to EncFS) to mirror some files with SyncBack Pro into the virtual Boxcryptor-Harddisk. Those get then encrypted by BC directly into C:\Dropbox\BoxcryptorTarget. The passwords to the EncFS volume are stored within Boxcryptor, so they have to be stored somewhere (maybe windows registry or something) locally on my computer. I don't want to re-enter it. I think this is not really a big deal, as this PW is not used anywhere else and should only avoid that someone eventually breaking in the Dropbox-Servers should not be able to decrypt files. I mean, if he gets access to my computer, I have problems anyhow... :-)

Things I don't like about the current setup

Now what annoys me a bit about using BC this way are those things:

  1. EncFS is not the "newest" algorithm and I read some things about it that it has some flaws
  2. When mirroring many many small files, Dropbox sometimes gets stuck slightly
  3. The software is still proprietary, even though it is at least compatible with EncFS which makes me more comfortable regarding security. But still, this does not say it couldn't contain backdoors or anything else.
  4. Apart from that, I'd love to use a more "powerful" encryption algorithm to make me even more comfortable about putting private files in the cloud, I'm a little bit paranoid but still love the backup-abilities here.

How I'd like to change my setup

As Dropbox supports synchronizing only the changed parts of TrueCrypt Containers, I thought about using a batch-script to mount the container file before mirroring files with SyncBack Pro, and then using another script to dismount after mirroring. This way, I would have ONE big container file, i.e. Dropbox would not have any problems synchronizing thousands of small files. Besides that, TrueCrypt is open source with a full source code audit and I could even use some cascades, i.e. AES-Serpent or anything... Performance is not the main goal when it comes to cloud-security IMO.

And here comes the question now

When I'd use the TrueCrypt workflow, I'd want an automated solution, that means, I'd need the batchfile to contain the password for the TC container file to mount it right before mirroring with SyncBack Pro. Is this a security flaw, compared to using Boxcryptor the way I currently am using it, when I put the TC-volume password right into the batch file which I'm using to auto-mount the volume before mirroring files? SyncBack Pro runs as elevated process to be able to mirror even "locked" files, so I could also make the batchfile only readable by admin-users, so that no other "simple" executable without elevated rights could read its contents. I know you should never save the PW plaintext, but I guess BoxCrytor and similar solutions also do it this way when storing the PW within the program so you don't need to re-enter it...?

Maybe I could also save the command-line instruction directly within SyncBack Pro instead of using an extra batchfile...

But as I said in the very first paragraph - I'm not really seeing the saving of the password as critical in that case, as someone breaking into my system would have won the fight anyhow...

Thanks in advance

Improve this question
5
  • So, what is the question?
    – BMC
    May 28, 2016 at 19:41
  • @BMC: Added bold highlighting
    – tim
    May 28, 2016 at 19:59
  • 2
    Just a note. TrueCrypt uses XTS, and using XTS in the cloud is a very very bad idea. XTS leaks a significant amount of information when incremental changes can be correlated across time.
    – forest
    Dec 20, 2017 at 8:29
  • @forest I'd amend that to say that disk encryption in general is a bad idea when an attacker has repeated access to the storage device. CBC and CTR suffer from malleability attacks, and in general disk encryption isn't authenticated.
    – AndrolGenhald
    Dec 20, 2017 at 14:51
  • @AndrolGenhald Indeed. The only time it would be safe is if you used AEAD or something like dm-integrity with CBC-ESSIV.
    – forest
    Dec 21, 2017 at 0:53

1 Answer 1

Reset to default
1

Storing the password on a script is not recommended irrespective of which ever technique you may be using. One work around would be to store a random file on a flash drive and use it's hash (or value from it) as the password. So that you can remove it when not in use.

Improve this answer
2
  • Yes, but how is it compared to saving the PW within BC. Isn't it the same as saving it now within Syncback or the batchfile? And whats the problem about it in this case? The PW is unique to this TC-container and I only use it to protect against someone breaking into my Dropbox (which will be hard anyhow as I use 2-step-auth). But I mean, if someone who got access to my Dropbox, now also gets access to my computer to read the PW - then i've got other problems anyhow isn't it?
    – tim
    May 29, 2016 at 6:33
  • The passwords in Syncback are stored in the Windows Profile folder. Which I assume would be were you store the file you create too. The Profile folder that contains these are protected by windows from other users. so would have to say yes it is kind of same. If it is to protect the data in DP, this will work fine.
    – BMC
    May 29, 2016 at 6:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .