New Dropbox Issues and a work around

More issues have been found with Dropbox, they were major issues and the researchers worked with the vendor to fix them before going public.Although they are now fixed they highlight the time bomb Dropbox is for enterprise users as usage convenience and security risk ignorance means sensitive information is likely to be transferred centrally on Dropbox from many different companies and user profiles.

The 3 security issues discussed in the this article were:– Hash value spoofing to access other customer’s data– Stealing Dropbox hostID to access other customer’s data– Potential replay attack when providing other customer’s data hash combined with any valid host ID (i.e.: the attacker’s host ID) to get access to the corresponding data.

One key point made in the article is that all this happens in the cloud, therefore the victims and/victims networks would be blind to these attacks.

There is no denial that Dropbox is very convenient, but those repeated security issues really means your data is at risk when hosted on their servers.

One solution, in this case, is encryption. I have listed a number of “on the fly” encryption solution in a previous post. But none of those solutions really ticked all the boxes so far, they either do not support enough OS, are not OpenSource and from very young and unknown companies, etc.

I have also previously said that using TrueCrypt would defeat the main attraction of Dropbox: seamless, streamlined and constant backups.

However, right now I see it as one of the only solution for securing Dropbox.

Why?Because TrueCrypt is a well established encryption solution you can trust. Of course, other encryption tools such as PGP and co could fit the bill too, but I like TrueCrypt because it is free and OpenSource.

For using TrueCrypt with Dropbox and not trade off security for performance too much you would need to be more disciplined though…In essence you need to break down your data into chunks in different containers so the TrueCrypt disks are as small as possible and the chunks of data that are not likely to change do not get sync up everytime you update a document which is unrelated to that data.

What worked for me is the following:– Store data you consider as public into a public folder , you don’t have to share it with the world, but need to assume it could be.

– Within your folders create some subfolders about data that is likely to change and data that will noti.e.: {Subject1_New, Subject1_Old} and {Subject2_New, Subject2_Old}, etc

– Keep the Change/New folders small

– Breakdown the Nochange/Old folders into sizes of around 500Mb or 1Gb maximum

– Create a TrueCrypt disk for each of the folders (Old and New).

– Ideally you will have a different passwords for each of the TrueCrypt disks but it depends on what process you use to remember those passwords!

– Store the public folder in Dropbox unencrypted

– Store all the TrueCrypt disks into Dropbox

Now, you will have access to your “public” data as before but for any potentially sensitive data you will have to mount the TrueCrypt disk before. You will also have to umount the disk before it can by synchronised back.

Because you have broken down your data into different chunks/encrypted disks, if you update or add a document into one of those disks it should not take long to synchronise back to Dropbox when you unmount it.Also, the old/reference data which you are unlikely to change can be accessed by mounting those larger “old” disks without requiring for a large and lengthy re-sync.

What you are introducing with the method described above is added security through a check in/check out process while leveraging performance by dividing your data into chunks.

More importantly, you are securing your data without relying on Dropbox security.