Sensitive files in the Cloud: Automated mounted TrueCrypt volume

Question

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

Answer 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.