

Show HN: I made tarbackup.com for you, what do you think? - nanch
http://tarbackup.com

======
Cyranix
Your Git repo doesn't inspire confidence for usage by the public at large. If
you want to continue using it, I would recommend that you change it over to
friends-and-family access while you improve it.

A few things that don't impress me right off the bat:

    
    
      * text file for queue of users to create
      * not accepting passwords with non-alphanumeric characters 
        (and also not having the knowledge to recognize a use case
        for a regular expression)
      * using a static salt
    

To be honest, I just stopped looking at this point. That's all without
actually looking at the front-end of it (which has several typos, by the way
-- when you're selling yourself to a very large audience, every detail
counts).

~~~
nanch
Thank you for looking over the code and providing your honest criticism.

* the textfile doesn't seem like a problem to me, just another version of a DB, what would be better?

* I updated the password to accept any password, not just alphanumerics

* I updated submit.php to use a random 16-character salt rather than the static salt

I'll look over the site to see if I can find those typos ;)

~~~
viraptor
> the textfile doesn't seem like a problem to me, just another version of a
> DB, what would be better?

It's not atomic at all. You could at least use bdb, or sqlite.

~~~
nanch
great point! I'll fix this; probably by adding some file-based locking for
simplicity's sake.

------
JoachimSchipper
From your "how to use" page:

    
    
        # echo mysupersecretkey > /backups/key
        # openssl enc -aes-256-cbc -salt -in fullbackup.tar.gz \
            -out fullbackup.tar.gz.enc -pass file:/backups/key
    

Please don't do this. openssl -aes-256-cbc is _not_ a strong key derivation
algorithm, so you need to use keys with much higher entropy (dd if=/dev/random
of=/backups/key); an attacker can run through a dictionary of common passwords
ridiculously quickly, thousands of times faster than when you're using a
proper key derivation algorithm, e.g. bcrypt/scrypt/PBKDF2 to generate the
key. If you do want to derive it from something akin to a password.

More seriously, openssl -aes-256-cbc does not do any integrity protection; in
fact, an attacker can more or less flip any bits of his choosing in the
ciphertext to flip those same bits in the plaintext. (Yes, I'm aware it's a
tiny bit more complicated than that.)

It _is_ possible to fix both of the above, but may I recommend gpg --symmetric
as a simple and reasonably secure alternative?

~~~
nanch
Great feedback, I'll change the "how to" ASAP after some reading on the
subject. Is there a secure command option that I can use with openssl instead
of -aes-256-cbc?

I originally tried to provide an example for openssl and gpg, but the gpg
example ended up with a dependency on X11 via a dependency on pinentry so I
took it out for simplicity.

~~~
JoachimSchipper
OpenSSL sadly does not offer any authenticated encryption modes, so you cannot
just replace -aes-256-cbc by something and be secure. There are basically two
things that work: either authenticate the ciphertext [1] by having the user
store a secure hash of each archive ("openssl sha512"), or switch to public-
key crypto.

Since the first is just inviting disaster - users aren't _actually_ going to
verify hashes - I recommend the second option. It's possible to build this on
top of "openssl pkeyutl", but gpg is a lot nicer. If I were you, I'd just use
gpg - some OSes/distros may pull in lots of stuff, but requiring a _running_
(as opposed to installed) X server to run gpg is incredibly unlikely.

[1] Always authenticate the ciphertext, never (just) the plaintext. See
"padding oracle attack" for one practical reason why - getting a recognizable
error when decrypting mangled ciphertext allows one to fully recover the
plaintext. "Recognizable error" includes timing information. Just make sure
you always authenticate the ciphertext.

------
tisme
See: tarsnap.com

~~~
nanch
tarsnap looks nice. somebody else had mentioned that service too, I figured
I'd go over some of the differences.

tarbackup is free, tarsnap is $0.30/GB/mo; tarbackup doesn't require a
separate client download; tarbackup was made just for fun, tarsnap is
commercial; tarbackup uses a private server, tarsnap uses S3

~~~
tisme
Tarsnap is secure, made by someone who understands security. Backups are
synonymous with reliability and security. Trusting an unknown entity with free
backups on a service made 'for fun' makes me wonder:

\- how long it will be around

\- how you plan to stay alive in the long run

I really wonder if you've thought this one through. Backups are rarely if ever
for fun, when you need them you need them badly.

~~~
nickwoodhams
Agreed, I am more confident with Amazon S3 as opposed to an undisclosed
private server.

I like that the instructions guided you through creating a secured tar file.

I like the idea of Tar backups, but no offense to you, I just don't trust the
reliability. You can't offer a resilient backup service entirely free, it just
doesn't work. Storage costs money, and developers know that better than anyone
else.

That being said, the actual code looks pretty simple.

Think you're on the right track here. Don't think I would pay for the service
though.

------
ysleepy
I see that you are passionate about this.

After I wrote a paragraph about how you could use the hardware for a shell
server, static (octopress/jekyll) website hoster etc. I realised, that free
backups are actually really awesome.

For people who cannot afford another service or dont have access to a credit
card or else. Also fpr my most important data like code as a second backup if
all goes wrong.

Thanks for the service, I will probably actually use it.

But it being a fun project and only behind 5mbit upload, this is obviously not
a professional solution or could be offered for money.

~~~
nanch
"Free backups are really awesome." love that line :)

My pleasure, I hope you do use it!

We'll see how much use it gets. I could put the box on a 100mbps if people
start using it.

------
genwin
Thanks! I understand what this service is: free "cloud" backup, no guarantees.
I have no problem with the latter part, given the former part. I'll use it
accordingly and appreciate your gift.

~~~
jarek
> backup, no guarantees

What's the use?

~~~
genwin
It's useful for a secondary or tertiary backup.

~~~
jarek
If your data is important enough that you want a secondary backup just in case
both your main source and your backup are both taken out, you would presumably
want it to be a reliable service, not a free hobby service on someone's home
cable connection.

If your data is not that important, why bother with secondary backup?

~~~
genwin
Good points. I already have three methods. This would be one more, in the
extremely unlikely event that all the others fail. A fourth backup would be
overkill if it wasn't free.

~~~
jarek
I see the reasoning, but I can't help thinking that any event that would
disable two or three well-planned backups is also rather likely to disable the
fourth - especially if that one comes with no guarantees. I'm thinking that in
the event of a major natural cataclysm, societal upheaval, etc, tarbackup.com
is not going to be foremost on nanch's mind.

I think this service could be most useful for spreading out the risk. For a
user outside North America with a backup drive in their house and another
backup somewhere else on their continent, adding an extra one in the U.S.
might make sense. If your backups are already on S3 in Oregon it's probably
realistically less useful.

~~~
genwin
Good points again. I try not to underestimate poor planning on my part. My
tertiary backup is an email attachment to myself. Someone might hack my
account to make it inaccessible.

It's interesting to me that people depend on tarsnap, when it could become
inaccessible if something happens to the author. Maybe tarbackup is better
since at least it's free.

