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

I knew a guy who always had headaches

[BadAnalogyGuy]

This guy was always complaining about headaches. He would constantly be pounding his head into his fist and whimper to me that he felt like his head would split open. He took pain killers all the time, and for a long duration was addicted to a certain prescription pain medication. But none of that helped because as soon as the medication started to wear off, the pain would come right back again.

Finally, I had had enough of his complaining. I told him to stop pounding his head with his fist. Whaddayano! His headaches went away in a day.

Moral of the story: Don't try to find workarounds for your problem. Fix the problem.

Re:I knew a guy who always had headaches

[elronxenu]

The problem is asking questions to Slashdot?

Re:I knew a guy who always had headaches

[GigaHurtsMyRobot]

If you don't really care about your data, why are you asking slashdot how to keep it safe? You already have the answer, it costs $10, now get off my lawn.

Re:I knew a guy who always had headaches

[ettlz]

Hey, I'm already doing that! The problem there is putting a Python installation on my portable drive.

What about Portable Python?

To me, the problem seems to be if someone has implemented a secure pseudo-filesystem over FTP. I tried looking for that but couldn't find anything.

If I understand your problem, you want the remote image encrypted, right? In which case SFTP/FTPS is redundant overhead (and whatever data is sent is stored in its plaintext). This is something that might be possible with FUSE (e.g., use the Python-FUSE bindings to construct an FTP client that passes stuff through GnuPG first).

Thanks for the laughs.

Heh, you'd be surprised how many people around here lack a sense of humour.

Re:I knew a guy who always had headaches

[stephanruby]

Yeah, I don't get this guy. First, he says he wants it for his home computer. Then, he says it has to be multi-platform (Windows and Linux) plus stand-alone that can be run from a portable drive.

And I say why? Let's assume for a moment that this guy has two computers at home, one that runs Linux and one that runs Windows. He doesn't need an app that does everything perfectly on both platforms. He just needs an app that does it perfectly on one, and either one is fine really. If he prefers to use his Linux box to coordinate the secure backup to an untrusted FTP site, then he just needs to have his Windows machine send the data unencrypted over to his Linux box -- then his Linux box can just do the bulk of the job. Or if he prefers to do it the other way around and use his Windows machine to do the secure backup to the untrusted site, he can just use that and have his Linux box send the data unencrypted to his windows machine.

And of course, why does it even need to go onto FTP instead of SFTP? Instead of wasting valuable man-hours reinventing SFTP from scratch, or finding someone else that has, he could just pay a few dollars to a provider who will give him SFTP. And if his current Provider won't do that, get an other additional provider that will do it. If backing up is really as important as he seems to make it, then spending a few extra dollars each month shouldn't be a problem.

Re:I knew a guy who always had headaches

[mccabem]

#10,407's got you by 1,132,922 membership points, #1,143,329.
#10,407 and #44,513 both want you off HIS lawn right now.

Sincerely,
Membership Police

Re:I knew a guy who always had headaches

[Bastard of Subhumani]

"Get Python, and code it yourself, schmuck!"

You appear to have misspelled "perl".

Re:I knew a guy who always had headaches

[B'Trey]

The real problem is not knowing about rsync since it's designed for exactly his problem.

No, rsync isn't a very good solution for a couple of reasons. First, unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities. Given an unencrypted file tree and an encrypted version of the file tree, rsync has no way to compare the two for changes. The only solution to that which I see is to maintain a local encrypted mirror of your file tree. So then you need twice as much space, since you're maintaining two local file trees, and you need a tool to update automatically sync the local file tree and the local encrypted version of the file tree. If you have that tool, then it may work or be hacked to work with a remote file tree, completely removing the need for rsync. Even supposing that you found a tool to do that which won't work with a remote file tree, you're nullifying the primary advantage of rsync.

rsync is designed to do incremental updates. If you have a text file and change one word, rsync doesn't transfer the whole file. It only sends enough info to correctly update the remote file so that it matches the new local file. (Or vice versa, of course.) But when you change a single word and reencrypt a text file, the whole file changes. So rsync will have to transfer the whole file. So will any other solution, of course, but it does mean that rsync loses much of the capability which makes it so valuable.

You could do something like unencrypt the local file tree mirror, rsync with the working file tree, reencrypt the file tree and then rsync the local encrypted tree with the remote encrypted tree mirror, but that's a lot of work and processing power and hardly matches the clean, integrated solution that the article is asking for. It's probably more cumbersome than whatever it is he's doing now.

Re:I knew a guy who always had headaches

[Slurpee]

go home kids. You can come back and play in the morning.

Re:I knew a guy who always had headaches

[mishehu]

It appears that there are options for rsync encrypting files on the far end. rsyncrypto might be just one of these. I have not used them but I remember them coming across my 'radar screen' in the past.

Re:I knew a guy who always had headaches

[B'Trey]

Interesting. Things like this are why I always hedge my bets and say things like "...unless there's some capabilities that I'm not aware of, rsync has no encryption capabilities..."

That being said, I'd be extremely leery of this program. The website says: "Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files." I'm far from an expert at crypto but I know enough to be extremly suspicious of that claim. A "slight change" in an encryption algorithm can be enough to transform an algorithm from highly secure to trivially crackable. And I strongly suspect that making similar files produce similar encrypted files means that there's a great deal of info about the unencrypted file suddenly available from examining the encrypted file. I wouldn't trust this without extensive review from some heavy weights in the crypto field.

Re:I knew a guy who always had headaches

[ashp]

In my day we tied an onion to our belts..

Re:I knew a guy who always had headaches

[ryder]

get offa my lawn!

Re:I knew a guy who always had headaches

[mdmkolbe]

Rsyncrypto is insecure. By resetting to the IV, it opens an information leak similar to the one with ECB mode (see the picture of the penguin on that page).

To see why CBC with occasional reset-to-IV is insecure (regardless of trigger function), consider a long repeating pattern of the same bytes (e.g. the white spaces in the penguin picture). CBC won't encrypt them to the same value (like ECB does), but every time the IV resets the same sequence of encrypted bytes will appear. This pattern is detectable and further the places where this pattern is disrupted is detectable. So going back to the penguin picture, the non-background portions will have a shadow that disrupts the repeating background pattern and revealing the content of the file.

Re:I knew a guy who always had headaches

[Sun]

Note - I'm the one who designed and wrote rsyncrypto.

The only obvious leakage is that an attacker can tell if two files are substantially identical.

Well, no. Two files will likely be encrypted using different session (read - AES) keys, and therefor will not be even remotely similar. One file having two significantly similar areas will show up, however. This case was deemed somewhat remote in my analysis. You are free to perform your own, of course. If you do, please feel free to email me.

The only place where actual data leakage may happen are due to the fact that a persistent attacker can compare cipher texts, and know where the decision function triggered. This is a good point to ask "how much information is gleaned about the file".

I think current rsyncrypto is ok on that front, and future plans include improvements. These improvements, alas, will cost in performance.

Shachar

Really is a pity

[pembo13]

I have explicitly asked my web host provider for either SFTP or FTPS. They basically said that it wasn't possible to provide that on a shared host. This seems untrue to me, I just can't state it as a fact since I haven't attempted it myself. But to get what the OP wants, one would essentially need a secure file system implementation on top of FTP. Ie. only the client can see the unencrypted file, not the in between transport over FTP, or the server side disk drive.

Re:Really is a pity

[ThePromenader]

I'd translate "wasn't possible" to "couldn't be bothered". Once SSH installed (and it is there by default in most *nix distros), you have but one 'user' file to configure (to 'jail' you within a certain hierarchy). Ta-da! Change your host and use SFTP.

Re:Really is a pity

[EdIII]

It is ENTIRELY possible to provide that on any host, regardless of the number of users. All you are asking (correct me if I am wrong) is that the connection between you and the FTP server is secured through SSH or TLS.

That is trivial. Sounds like they cannot be bothered to enact rudimentary security. As a policy in my own systems, and any systems that I pay to use, I demand that any connections that go over untrusted networks be encrypted. There are so many products that help you do this it just makes their refusal all the more ridiculous. I have a product that does not support encrypted connections and I just stunnel to protect it.

Anything less is just reckless. Tell them to protect your connection or you will get another provider. Simple as that.

Re:A slight oxymoron here.

[Whiney Mac Fanboy]

"secure" and "untrusted" don't go hand in hand. If you want security, don't put things in untrusted spaces. Period.

Are you sure about that? I consider my SSH connections secure even tho' they traverse untrusted links. Same goes for my encrypted mails, https connections to my bank, etc.

Anyway, to the submitter - is areca close to what you want?

Re: Errr

[Whiney Mac Fanboy]

Am I the only one thinking this is like someone saying they want privacy then running around butt naked then wondering how they can keep their privacy at the same time.

And the answer of course is security through obscuring. Wear a mask ;-)

(I guess you're not completely naked, but hey, close enough)

TrueCrypt

[kcbanner]

See http://www.truecrypt.org/ for cross platform encryption...you can throw your files in there.

Re:A slight oxymoron here.

[Anonymous Coward]

"secure" and "untrusted" don't go hand in hand. If you want security, don't put things in untrusted spaces. Period.

I disagree. Everywhere you can store your files should be considered "untrusted". And "securing" the files is what we do to mitigate that reality.

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.

[Sparohok]

If you want security, don't put things in untrusted spaces. Period.

Completely, utterly incorrect. It's a sad comment on the ambient understanding of data security that this got modded insightful.

Trust is seldom a good approach to security. Good security is when you can trust nobody and still sleep at night. That means strong encryption. That is exactly the approach implied by the article and it is exactly the right thing to do.

I think it is very unwise to ever assume any level of trust in the storage of backups, certainly offsite backups. The whole idea of backups is that you keep them around for a long time, in several copies and several locations. The more valuable your data, paradoxically, the more copies you need and the more widely dispersed they should be. This is antithetical to maintaining trust. The right way, indeed the only way out of this paradox is strong encryption.

Re:Errr

[Anonymous Coward]

Even if his userid/passwd are compromised, his data wouldn't.

So if someone used his userid/passwd to delete his archive or overwrite it, his data wouldn't be compromised?

Or has the data no value, so the archive can be deleted/corrupted without loss? Then what is the use of archiving it at all?

Manent fits the bill perfectly.

[gsasha]

Well, it's feature list is exactly what you want and some more :). Here's the project description:
Manent is an algorithmically strong backup and archival program. It features efficient backup to anything that looks like storage. Currently it supports plain filesystems ("directories"), FTP, and SFTP. Planned are Amazon S3, optical disks, and email (SMTP and IMAP). It can work (making progress towards finishing a backup) over a slow and unreliable network. It can offer online access to the contents of the backup. Backed up storage is completely encrypted. Backup is incremental, including changed parts of large files. Moved, renamed, and duplicate files will not require additional storage. Several computers can use the same storage for backup, automatically sharing data. Both very large and very small files are supported efficiently. Manent does not rely on timestamps of the remote system to detect changes.
Check it out: http://freshmeat.net/projects/manent. It's under active development (the UI and the setup are currently in fetal stage) but the basic functionality is there and is well tested.
Disclaimer: I am the author.

Re: Errr

[houghi]

A rabbi and a minister went swimming naked at a lake when some children came. Both ran out of the water to their clothes.

The minister covered his 'private parts' while the rabbi covered his face. When the minister asked why the rabbi did not cover his genitals for the children, the rabbi said : "Hey they recognize me by the face."

Well, I've also looked into it and found nothing

[gsasha]

So I wrote it myself. http://freshmeat.net/projects/manent

Re:vanilla ftp: your password will be in the clear

[GauteL]

This may well mean that despite whatever you do, encypt etc, someone can sniff the password and then simply come in and delete all your files.

i.e, whatever other steps you take, this is inherently worthless.

Hardly. As long as the data is encrypted well enough to stop people from stealing or modifying the data in ways that could have serious privacy and financial implications this is a net gain in data availability.

Even if the chance of someone doing this was as high as 5% over the period in question, it would still mean that there was 95% chance of you having a good off site backup. That is better than nothing as long as you realise that there is still a 5% risk and don't act like it is totally secure.

As a simplified example; if your PC at home is 95% sure of retaining all of its data in the period and your portable USB hard drive is 95% sure of retaining all of the data, the chance of you losing any data at all is 0.0125%. Even with exaggarated risk factors, this is not bad.