Secure File Storage Over Non-Trusted FTP? 384
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."
I knew a guy who always had headaches (Score:4, Insightful)
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:A slight oxymoron here. (Score:5, Insightful)
"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 [sourceforge.net] close to what you want?
Re:A slight oxymoron here. (Score:4, Insightful)
"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.
Re:A slight oxymoron here. (Score:5, Insightful)
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 (Score:5, Insightful)
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?
vanilla ftp: your password will be in the clear. (Score:4, Insightful)
Re:I knew a guy who always had headaches (Score:5, Insightful)
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:duplicity + ftplicity + Portable python (Score:3, Insightful)
Then you should have put this as a requirement in your query. But I would ask WHY you want a gui? Backups should be set-and-forget! My USB sticks have multi-platform autorun scripts to execute my backup. I only need an interface if I choose to expand or shrink the backup set--I can edit a text file that has the list of what to exclude.
Python is pretty easy to put on a portable hard drive and there are multiple [portableapps.com] portable [portablepython.com] versions [voidspace.org.uk].
Re:A slight oxymoron here. (Score:3, Insightful)
Access means they can decrypt them. Given enough cycles, encryption can be broken.
What are you talking about? Encryption that can be broken with any feasible level of computing power is worthless. If you're assuming that once the bad guys get your ciphertext they'll be able to decrypt it sooner or later, why encrypt your data at all?
Certainly I'd prefer to have my valuable data stored with both physical security and encryption. But if I had to choose one or the other, I'd definitely choose encryption. If you compare the cost of the security measure with the cost to circumvent it, strong encryption is many orders of magnitude better than physical security.
Re:I knew a guy who always had headaches (Score:4, Insightful)
The real answer to your problem is use a secure protocol like SSH which does everything you just asked for natively.
Does it encrypt and sign the files one-by-one so that the admin of the remote site (who you don't trust) can't read, alter or share them on you?
Re:A slight oxymoron here. (Score:4, Insightful)
All encryption can be broken. The solution then, is to ensure that the encryption cannot be broken within a useful timeframe. I really don't care if you manage to decrypt my credit card number if the card has already expired. If I'm having a secret meeting this time tomorrow then the encryption only needs to last just over 24 hours, since by the time you work it out it will be too late.
I actually think you've got it backwards. Encrypt them strongly and you can put the data on a billboard in the centre of picadilly circus and no one will be able to work it out in a useful timeframe. Ever seen Kryptos? http://en.wikipedia.org/wiki/Kryptos [wikipedia.org] The data is public, there are many thousands of people attempting to break it, and yet the hardest section remains unresolved. The acceptable risk is related to the minimum amount of time that you can allow for the code to be broken, which determines how strong you need your encryption.
Re:I knew a guy who always had headaches (Score:3, Insightful)
is the password "cleartext"? Because it is.
Sniffing FTP passwords is a joke!
Re:vanilla ftp: your password will be in the clear (Score:5, Insightful)
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.
Re:I knew a guy who always had headaches (Score:4, Insightful)
The problem is FTP. It is an old deprecated protocol that is inherently insecure and even FTP w/ SSL is simply a work around to a broken problem.
Wow. It might be better to understand the problem before you make suggestions. FTP isn't the problem. FTP is just a way to move files from here to there. It's unsecured and untrusted but, in this case, SO IS THE REPOSITORY. Exactly what benefit do you get from using SSH to securely transfer files to an unsecure location? That's like using an armored truck to move your valuables to the QuickStorage down the road. What's wanted is an automated way to encrypt the files locally, then transfer the encrypted files to an untrusted site. If the files are encrypted, then it doesn't matter that FTP is unsecured.
Re:I knew a guy who always had headaches (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Insightful)
Does it encrypt and sign the files one-by-one so that the admin of the remote site (who you don't trust) can't read, alter or share them on you?
If you don't trust the remote server, why the fuck would you consider using it as a backup site?
There isn't an encryption/protection scheme possible that will prevent the remote admin from outright deleting whatever files on his own filesystem that he wishes to. Oops, no more backups.
Re:A slight oxymoron here. (Score:3, Insightful)
I think you've missed the point. If you're not allowing access to the files then encryption isn't particularly important now is it?
The whole point of encryption is that you could email it to your arch-nemesis and they would still be unable to decrypt it in a useful time-frame. Take AES with a 256 bit key. That would (on average) take all of the computers in the world millions of years to brute force. It's possible that someone could get lucky, but they'd have to dedicate years of processing time on the off-chance that you had encrypted something particularly juicy.
Re:I knew a guy who always had headaches (Score:3, Insightful)
I haven't read the page in detail but this appears to be a tutorial on using rsync over ssh. That would encrypt the transmission but it wouldn't result in an encrypted file on the other end. Am I missing something?
Re:I knew a guy who always had headaches (Score:3, Insightful)
It might be safe but unless you're quite knowledgeable about encryption, gut feelings about what seems safe aren't very reliable. I still suspect that doing this opens up more areas of attack. Note that I'm making no claims of expertise, so I don't KNOW this to be the case. I'm just saying that I'd be leery.
Re:I knew a guy who always had headaches (Score:4, Insightful)
What's wrong with using a public key for the backups? That's what I do.
If you're using purely symmetric encryption for your backups, you have to store the keys somewhere, and that somewhere has to be online when the backup is generated. Then you have to physically move it somewhere that it's not reachable. It's a manual process.
With a public key system, you can store your private key offline all of the time, and not have to deal with symmetric key management. GPG does that for you.
Where is the downside?