Slashdot Mirror

Tarsnap

These are more techie-oriented rather than for general desktop use (they don't have shiny GUI sync clients, and are aimed at Linux/BSD users), but two I'd recommend:

rsync.net. Remote ZFS filesystem you can scp files to, or access over ssh via a restricted shell that supports a range of backup tools. For encrypted backups, if you're on a unix machine, you can point duplicity at it. They've been around a long time, and have a warrant canary, though if you encrypt the files client-side with something like duplicity, they won't even have your data in the first place.

Tarsnap. Encrypted, deduplicating incremental backup. The encrypted blobs are stored on Amazon S3. Custom client that by design keeps them from ever seeing the unencrypted data.

These are more techie-oriented rather than for general desktop use (they don't have shiny GUI sync clients, and are aimed at Linux/BSD users), but two I'd recommend:

rsync.net. Remote ZFS filesystem you can scp files to, or access over ssh via a restricted shell that supports a range of backup tools. For encrypted backups, if you're on a unix machine, you can point duplicity at it. They've been around a long time, and have a warrant canary, though if you encrypt the files client-side with something like duplicity, they won't even have your data in the first place.

Tarsnap. Encrypted, deduplicating incremental backup. The encrypted blobs are stored on Amazon S3. Custom client that by design keeps them from ever seeing the unencrypted data.

Yes, and scrypt would be even better than that.
Look here, there is a comparison between the three on page 14.

>Most people would just suggest to store it in "the cloud", but I'm naturally averse to doing so because that means someone else is responsible for my data and I could loose (sic) it to hackers, the entity going out of business, etc.

Simply strongly encrypt your data before backing it up to the cloud, you will be at no risk of hackers or anyone else gaining access that way. If you can't find a cloud storage service that you trust/trust won't go out of business, you can make your own cloud using Amazon's AWS system. The levels of security at the facilities and redundancy mean your data will survive anything short of nuclear Armageddon. Personally I'd just go with the local encryption option.

I can't tell if you're joking, but since you are currently at +5, Funny, I'll just leave this here.

Tarsnap does exactly as you suggest, without the need for you to build it on your own. Its client is read-only open source software encrypting your stuff locally, then sending it out to Amazon to be stored. The client sports a tar(1)-like interface and runs on basically any POSIX OS variant, including Cygwin.

Price: 250 picodollars per Byte/Month (Yes, Really.)

Check it out!

(Reposted my previous anonymous comment, so it might not be lost. Disclaimer: not affiliated with above-mentioned company.)

I can't tell if you're joking, but since you are currently at +5, Funny, I'll just leave this here.

Tarsnap does exactly as you suggest, without the need for you to build it on your own. Its client is read-only open source software encrypting your stuff locally, then sending it out to Amazon to be stored. The client sports a tar(1)-like interface and runs on basically any POSIX variant OS, including Cygwin.
Price: 250 picodollars per Byte/Month.

Not a joke. Check it out!

For client-side encrypted backups, duplicity is popular, however it is a bit too buggy in edge cases for my taste.
dar is similar but seems more mature, however takes up more space (deduplication is less efficient than Duplicity) IIRC.
For offsite online backups you can check out: Tahoe-LAFS, Obnam, tarsnap, brackup, attic.

Colin Percival at https://www.tarsnap.com/ He knows what he is doing. And my local storage.

Data migration and expanding RAID containers is a major PITA. I absolutely loath the task!

That's why you don't use RAID. Instead, use something more flexible. I've been running Greyhole for a while now. Adding storage doesn't require shifting files around (unless you want to rebalance storage), you can use drives of different sizes, and you can control the level of redundancy you use (more for important files, less for stuff that's easily replaced). You can yank a disk out of a Greyhole installation and read all of the files off of it with standard file-copy tools.

Important stuff that doesn't take too much space (documents, Git repos, etc.) is backed up daily to Tarsnap. Less-important stuff (movies, music) and larger files (photos) get dumped to BD-R and are stored in binders in my desk at work; images are prepared with dvdisaster for added error recovery capability and are burned to single-layer BD-R HTL media.

Tarsnap offers NSA-proof cloud storage and provides all the source code for all the client programs to back up their claims (in fact the installation is only available in source code form). But it costs way more than the competition.

Instead of wasting time throwing your pearls of wisdom before these unappreciative simpletons, why don't you head over and take a look at Tarsnap?

He'll pay a bounty for every bug you find. Even for typos! (Though small bounties are paid in Tarsnap credit.)

With an (effectively) infinite number of bugs, that's infinite money! Your amazing insights on software quality and mathematics could make you rich!

Instead of wasting time throwing your pearls of wisdom before these unappreciative simpletons, why don't you head over and take a look at Tarsnap?

He'll pay a bounty for every bug you find. Even for typos! (Though small bounties are paid in Tarsnap credit.)

With an (effectively) infinite number of bugs, that's infinite money! Your amazing insights on software quality and mathematics could make you rich!

I'll stick with SpiderOak and TarSnap Fully encrypted, zero knowledge from their end. A bit more money but good peace of mind.

Pitty they are all in USA, any that are NON usa based?

Tarsnap, by Colin Percival (author of the scrypt algorithm).

It's based in Canada and, although the slices of data are stored on Amazon S3 (USA), the actual data-encryption and key handling is done on the opensource source client (which is audited a lot, thanks to a bug bounty by the author).

Specially, the kind of mismanagement that happened to TFA's Author is impossible with tarsnap.
Access and the various key which control who has access to what are controlled by the client. The admin (in this case: Colin Percival himself) can't do much without the keys which aren't available to him (they are stored client-side). The only thing which goes from/to the server are encrypted packets of data.

Tarsnap is a bit less userfriendly for quick-sharing of files (what TFA's Author uses specifically the box.com account).
But on the other hand, tarsnap is perfect for periodical backups/snapshots (with deduplication) of the critical folders with critical information (authors gives dropbox and skydrive as exemples of share where critical informations is backed-up: work documents, financial data, medical records, etc.). Those would have been much more problematic if control was given to the wrong person, as the author mentions (for example: financial data ending in wrong hands would be a treasure trove of data for identity stealing. And if this data get erased by mistake, the author would be on trouble in case of IRS audit).
But that's impossible with scheme where the control is done using crypto keys, instead of a status in a database somewhere.
(Tarsnap data can't be made accessible to someone else. In fact, it can't even be made again accessible to you if you lost the keys. No keys, no anything).

The key derivation functions can be literally several orders of magnitude harder to brute force. And their difficulty can be chosen with simple parameters, with sane defaults. There is really no comparison between a singly salted hashed password and bcrypt/scrypt.

Check out table 1 in this paper to get a sense: https://www.tarsnap.com/scrypt/scrypt.pdf

ZFS can implement some backup on top of it's reliability - in that the snapshots can allow you to recover recently-deleted files, but it's not really a true replacement for a real backup - something that you can pull the files off of if your entire server goes down.

My home server has ZFS (with hourly, daily, weekly, and monthly snapshots that get cleaned up on a regular basis), but I also use tarsnap for regular backups. It stores encrypted (and deduped) incrementals of your data on an Amazon store.

My desktop mounts some of it's files (including a couple of whole users) from the home server, for the rest I use OS X's Time Machine - not quite as good as a remote backup scheme, but cheaper, and easy to set up.

It's an encrypted cloud-backup service rather than plain cloud-storage, but http://tarsnap.com/ makes the client's source available for your inspection.

I'm surprised it took someone this long to think of this.

Tarsnap, designed and developed by the FreeBSD Security Officer and security researcher (Colin Percival) is four years old.

Its BSD licensed client encrypts everything on the client - including file names - and then uploads it to Amazon S3.

It's awesome.

http://www.tarsnap.com/

Tarsnap is the best, most secure, and most interesting of these:

http://www.tarsnap.com/

Tarsnap charges $0.30/GB. Maybe this will allow them to offer another tier of service for cheaper.

Not true. It's absolutely fine to store your data on someone else's server as long as it's encrypted, you have the key and they don't. For example, using tarsnap for backups should not be a problem, because the data is encrypted on the client and uploaded. Someone I know just submitted a PhD thesis on storing data securely on untrusted servers (well, a bit more than just that) and it's quite possible. That doesn't solve the reliability issue, of course, you still have to trust the remote site to stay in business, and to have adequate redundancy and backups. Even that can be addressed by sending your data to multiple providers.

Or better: Tarsnap - "online backups for the truly paranoid".

I assume you mean http://www.tarsnap.com/scrypt.html and https://github.com/pbhogan/scrypt? Looks interesting, I'll have to check them out.

A better idea would be to switch to storing the SRP verifier:

x = H(s,p) ; s = salt, p = password, H() is SHA-1
v = g^x

Store v, s, and u (the username).

http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Anyone who can get the password (or even the hash) from the above deserves to get them. :)

I assume you mean http://www.tarsnap.com/scrypt.html and https://github.com/pbhogan/scrypt? Looks interesting, I'll have to check them out.

Tarsnap

There are some decent-looking hosted alternatives to dropbox which do client-side encryption. I've looked into this a bit, but I haven't tried any of these yet, so YMMV...

One particularly interesting one is TarSnap. The best part is the client is OSS, so you can verify that encryption is done properly (strong & client-side). You could even reverse the protocol and design your own server software, if you want.
http://www.tarsnap.com/

Another interesting one is SpiderOak. However their client is not OSS, so you have to trust that they're doing the encryption properly
https://spideroak.com/

Here are some other potential hosts, but I'm not sure exactly how proper the encryption is:
http://www.boxcryptor.com/
http://syncplicity.com/products/

It is well known that if someone gets your hashed password, it is as good as cracked. 17 minutes vs 4 minutes is irrelevant.

Bullshit. It is well known by people who don't know what they're talking about, which includes TFA.

Do you seriously think that in the age of bitcoin we can't make a hash function that is arbitrarily difficult?

Use an adaptive cryptographic hash function: bcrypt, PBKDF2 or scrypt. The key feature is a tunable stretch factor that basically sets the number of rounds of hashing. Set that factor (by means of a simple timing loop) to require 1 second of CPU time (or GPU time or whatever) to hash.

Now the simplest 8 character A-Z password will take an expected 3,311 years to break. You'll obviously want a safety margin, and will expect them to have more computing power a few years down the road. But you can tune the stretch factor to ensure that a reasonably strong password is perfectly good against offline attacks.

If you're hashing a password, use a slow hash, one that can be "stretched" to take seconds of CPU time. If it takes a second of CPU time to hash a password, your attacker is going to need 6622 years of CPU time to break an 8 character A-Z password, whereas you'll need one second to approve a valid user.

Don't try to roll your own slow hash by using many rounds of a fast hash, there are slow hashes that have been designed and reviewed by the security community. bcrypt is one I often hear about, but search around, there are others.

Agree entirely with you. However, you could do even better than bcrypt (which is very good already). The reason is that bcrypt (and the like) only depend on a lot of CPU time, but do not demand a lot of memory. CPU time is much easier to come by than memory, and easier to parallelise. One algorithm that uses both a lot of CPU time and a lot of memory is scrypt. The author estimates that (with the same constraints on the time taken to calculate the derived key from the password) scrypt is typically at least 30 times more expensive to an attacker than bcrypt.

More information on scrypt here: http://www.tarsnap.com/scrypt.html

If you're using anything other than PBKDF2, bcrypt or scrypt to store your user's passwords, you have already lost.

This is the point of tarsnap. Open source client, you can verify it and the encryption that it uses. It encrypts everything before uploading and can't be decrypted on the server without access to a key that's only stored in the client.

While most people know enough about security to avoid a plain password hash, very few people know how vulnerable common key derivation functions truly are. Things like PBKDF2, bcrypt and MD5-crypt widely used for example in Linux shadow file or in TrueCrypt give only a linear advantage over a salted plain hash. 5000 MD5 repetitions might sound like great security from a brute force perspective, but the asymptotic hardware cost of brute-forcing such a password is fairly small. The cost to break your 8 letter bcrypt password is in the hundreds of dollars, assuming enough passwords are cracked to justify a hardware cracker. I can almost bet NSA has a multi-million dollar hardware cracker that can brute-force your Linux or TrueCrypt password, assuming it has less than about 50 bits of entropy. Very few people are capable or willing to use truly safe passwords with 100bit+ entropy.

I know of only one strong key derivation algorithm that forces the attacker to scale it's hardware cost at the same rate as the software slowdown: scrypt. So by all means, don't use bcrypt, use scrypt.

The issue is completely different in a webserver, that probably can't spend 1 second of CPU time whenever a user logs in. Is such cases a hash + salt is all that you can realistically expect if a dedicated authentication machine does not exist. At least try to combine them safely using a HMAC, not some home-grown SHA1(salt+password) scheme.

Tarsnap would potentially do the trick:
http://www.tarsnap.com/

Tarsnap (http://www.tarsnap.com) positions itself as an “online backup for paranoids”, but should be easily usable for simple web-based storage.

Got you covered here.

http://www.tarsnap.com/

There are places that do this.

Tarsnap uses prepaid micropayments to back your data up to Amazon's cloud. Slashdot is a site which uses it to provide subscribers with a few nifty extras, and they deduct per pageview.

The thing is, for micropayments to work, you have to charge a large (relative to the costs per widget) amount all at once, and in most cases, consumers have to prepay.

I don't want to give my data away to some server outside without strong encryption

Man, no one reads anymore!

Depending upon how much work and money you're willing to expend, you might check out Tarsnap. It's not going to have a pretty GUI or anything, and you'll need Cygwin to get it running on Windows, but it's got pretty much everything you want.

It's snapshotting, so you only transfer small changes.
It encrypts (and it does so on the client, before sending it to the server) and the source code to the client is available for review. Unfortunately, the terms of use for the Tarsnap server do not allow modifications to the client. I'm not sure if this counts for your open source requirement.
The back-end is Amazon S3, much like Jungle Disk (though unfortunately, you wouldn't be able to continue using Jungle Disk to access this data, as you hoped.)

The biggest problem I have with it is that it doesn't do true syncing. There's nothing stopping you from writing a few scripts to effectively get syncing. I could envision storing/backing up your subversion repository with Tarsnap and downloading the last snapshot any time you need to start working on a new machine.

There's really not much else that suitable without running your own server somewhere.

A decent solution for smaller amounts of data. It sounds like the asker is creating lots of large files (all of his movies and TV shows on DVD.) If we assume a terabyte of storage, S3 is going to run him $150/mo, plus $170 just to transfer it all. For those prices, you could buy several terabyte hard drives, a lot of gasoline (over the course of a year) and a safety deposit box in your bank.

That said, for smaller amounts of data, S3 seems reasonable. I've just started trying out tarsnap ( https://beta.tarsnap.com/ ). The feature list is good, and the person coding it has been working on the FreeBSD project for a while (he contributed portsnap and freebsd-update, two projects which make maintaining FreeBSD much easier.)

Specifically, tarsnap uses a snapshot model similar to filesystem snapshots. This means that after the initial backup, you only have to save the changes, and you can delete snapshots without having to make a full backup or otherwise recreate the full set of data. It also compresses and encrypts the blocks, and it uses S3 for the back-end. Unfortunately, this means that you have to pay fees which are higher than Amazon's, which is why it isn't suitable for high volumes of data. The tarsnap client is open-source, though the server has not been released (and likely will not be.)

Right now, the author is using a prepaid pricing model, and he charges $0.30/GB transferred and $0.30/GB/mo storage--roughly twice Amazon's rates.

Like I said, I just started testing it to see if it will be viable for my users' home directories. The initial backup seemed to go well, though I haven't tried a full restore yet.

rsync to Amazon S3 might be an option, if only for cross-platform capabilities. No versioning though, but outside of Apple's Time Machine (obviously useless for Windows and Linux), you're not going to get that without some major headache

Um, there are plenty of incremental backup tools dotted about, just upload the dumps?

Alternatively tarsnap is currently in beta testing, uses Amazon S3, and the client is written by the top FreeBSD security bod, with the client coming as source (though the service isn't free).