Secure File Storage Over Non-Trusted FTP?

hmckee writes "Does any software exist that enables me to store/backup/sync files from my local computer to a non-trusted FTP site? To accomplish this, I'm using a script to check timestamps, encrypt and sign the files individually, then copy each file to an offsite FTP directory. I've looked over many different tools (Duplicity, Amanda, Bacula, WinSCP, FileZilla) but none of them seem to do exactly what I want: (1) multi-platform (Windows and Linux), stand-alone client (can be run from a portable drive). (2) Secure backup (encrypted and signed) to non-trusted FTP site. (3) Sync individual files without saving to a giant tar file. (4) Securely store timestamps and file names on the FTP server. Any help or info on alternative solutions appreciated."

Comments

Working On Something Similar

[RAMMS EIN]

I'm working on a backup solution that allows people to back up their data to a remote server securely and efficiently. For "efficiently", think rsync: only the differences are sent (and some information necessary to identify what the differences are). For "securely", think assymetric cryptography: your backup is stored in encrypted form, so that only someone who possesses your private key can use it.

All this is currently in very early stages of design. I'd welcome any suggestions for protocols or software I could use. Currently, I am thinking to implement a transactional network block device protocol, and implement the backup protocol on top of that. I still need to decide on a programming language I can use for parts I need to write myself, too (something safe (no buffer overflows, please), yet with byte level access...and no Java or .NET, please).

By the way, this is going to be a commercial product, but the code and the protocols will be open. I'll charge for the storage and bandwidth. :-D

Re:Working On Something Similar

[davidkv]

Have you checked out rsyncrypto?

Re:Working On Something Similar

[Bert64]

Well, I use rsync over SSH (so the network traffic and authentication is encrypted)...
You could potentially use an encrypted disk locally, and rsync the encrypted disk image over (it should still only xfer the changes), assuming you don't trust the target host.

Re:Really is a pity

[Anonymous Coward]

Your webhost probably uses virtual accounts in the ftp server, or in some sort of db backend, that ssh can't talk to out of the box (ie not a real account). Plus, they don't want the overhead I guess, or the extra work for the 2 customers out of every 2000 who want it.

duplicity + ftplicity

[Horus107]

duplicity combined with ftplicity:

"Anyone storing data on an unfamiliar FTP server needs to encrypt and sign it to ensure reliable protection against prying eyes and external manipulation. duplicity is just the tool for this, and the ftplicity script from c't magazine makes working with it child's play."

http://www.heise-online.co.uk/security/Backups-on-non-trusted-FTP-servers--/features/79882
http://duplicity.nongnu.org/

Re:A slight oxymoron here.

[dolmen.fr]

It depends on what you put behind the word "security".
"Backup" is also "security". And a cheap of-site backup is better than no off-site backup at all.

I have the same need as the submiter as my ISP provides 10 GiB of public web space available only through FTP (r/w), HTTP (r) or HTTP+PHP (r/w). I have the storage, I need the software to use it while hiding backup content from my ISP and from other web eyes.

Re:I knew a guy who always had headaches

[hairyfeet]

Like pretty much every SMB I have ever worked on. It is really a shame there isn't an easy native way to run VB code in Linux,because every single SMB I walk into has some damned VB3-6 app that holds that place together. Worse is it always seems to be written by a guy named Chuck that worked there ages ago and didn't know WTF he was doing. I swear I opened up the last VB4 one to convert it to VB6 and try to fix the crashing and was like "OMFG! Tap dancing Christ what was this guy thinking! Was he high?".

The ENTIRE first page was nothing but a giant mess of GOTO calls. I'll admit I'll throw in about one GOTO per app just to do a quick function call,but DAMN. The entire first page was GOTO here,then GOTO there,then GOTO somewhere else. Luckily like a good 75% of VB apps out there it was a GUI connecting to a database so I was able to whip off a replacement. But it would be nice if just once they brought in an actual coder to write a program instead of clueless chuck. But as always this is my 02c,YMMV

Re:Really is a pity

[Builder]

I fully agree with this provider. Providing shell access to a shared machine is madness and you cannot provide security for your users this way.

SFTP requires that SSH be running, so there is always a risk of shell access being gained through breaking scponly or whatever other jail you use.

Virtual machines are the only way I know of providing this, and they cost more because of setup / maintenance costs. Failing that, FreeBSD jails, but they are unpopular due to people wanting Linux hosting.

You get what you pay for - live with it or pay more.

Re:I knew a guy who always had headaches

[MagdJTK]

Gah. I wish people wouldn't keep trying to use public key encryption when it's not needed. Public key encryption is used to get around the key distribution problem. Signing is used because anyone can easily encrypt stuff using your public key and you can't guarantee they are who they say they are.

From what I can tell, he's not sending these files to anyone. He's uploading them and the only person who will access them will be himself. This is exactly what regular, symmetric encryption is for!

Encrypt the files using AES or Blowfish or a combination. Truecrypt may be handy though I'm sure there are many other implementations. If you're keen on security use a password and a randomly generated keyfile which you keep safe on a USB stick (with multiple backups of course). The person on the other end obviously can't open the files without the key (which would take NSA millions of years to brute force). If he changes the files in some way then you won't be able to decrypt them with your key so you know something's up. No need for signing, GPG or anything particularly clever. As for sharing, who cares? Noone will be able to open them; that's the point of encryption.

Re:I knew a guy who always had headaches

[Anonymous Coward]

I use rsync with encryption all the time.
http://troy.jdmz.net/rsync/index.html
And I am syncing pictures (binary files) I take when I am away from home, it works pretty well for me.

Re:I knew a guy who always had headaches

[Sloppy]

Yep. I spotted that problem too. The fact that he has the requirement to use non-trusted FTP (i.e. can't install openssh) strongly suggests this ftp server is someone else's. His backup could vanish at any moment. Since he can't rely on this, then he'll still need to backup somewhere else too. So why not switch his attention to that "somewhere else"?

Re:I knew a guy who always had headaches

[Anonymous Coward]

Here's a review of rsyncrypto that also says it isn't really secure:

For an example of an information leak, suppose you have an XML file and you use rsyncrypto to copy the file to a remote host. Then you change a single XML attribute and use rsyncrypto to copy the updates across. Now suppose an attacker captured the encrypted versions in transit, and thus has copies of both the encrypted file before the change and after the change. The first thing they learn is that only the first 8KB of the file changed, because that is all that was sent the second time. If they can speculate what sort of file the unencrypted file was (for example, an XML file) then they can try to use that guess in an attempt to recover information.

Rsyncrypto encrypts parts of the file independently, thus keeping any changes you make to a single block of the file local to that block in the encrypted version. If you're protecting a collection of personal files from a possible remote system compromise, such a tradeoff in security might be acceptable. On the other hand, if you cannot allow any information leaks, then you'll have to accept that the whole encrypted file will change radically each time you change the unencrypted file.