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).
It doesn't seem to me that you're storing the per-user salt anywhere.
I'm glad you're working on a project that is fun for you. It will be an opportunity for you to learn quite a lot, but I would urge you to question your design choices and keep asking "How could this be done better?". Read about how other people have approached similar problems.
Get a small group of friends, family, and other technical acquaintances to pick this apart. I wouldn't endorse this for the general public.
Now that I'm waking up some more, I realize 1) you're correct, the salt is stored, but 2) you're using SHA-512 for password hashing, which has been repeatedly discussed as a bad idea for quite a while on HN.
This is the last I'll say on it: I am genuinely glad that you're trying out a project of this complexity, but you have a responsibility not to give others a false sense of security. If you search HN, you will find plenty of advice and reading material -- restrict this app until you have absorbed more of it. It's not enough that it works; strive to make it work well.
[Also, a nitpick just because it's killing me: please replace the entirety of isStringAllowed with a regular expression. \w{5,} would give you alphanumerics plus underscore and check for minimum length. Regexes don't solve every string-oriented problem, but they're a fantastic tool to have in your toolbelt.]
I disagree, congrats on releasing something! I think it is entirely appropriate to make it public and solicit feedback here. He has already gotten some useful stuff. Perhaps you could point him to "advice and reading material" that would be fruitful for him to "absorb" before he makes another gaff like getting on the front page of HN?
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?
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.
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.
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
How are you going to keep it free? What guarantee do you give that after trusting my data to you, you won't decide that your bandwidth and storage costs are getting out of hand and discontinue the service?
Not trying to be a sour grape here and talk you down, but these questions matter if you see this as more than a hobby thing and are serious about it. If you plan to take this further: find a way to make it sustainable. If not: why not release the code?
I'll keep it free by not requiring payment! :) I've already put $2.5K+ into the box just for fun. I don't expect to recover any costs; I'm just providing a service for people. Even if nobody actually needs to restore their data, at least they could if they wanted to.
There are no guarantees, but I have a 20Mb/5Mb internet connection that's just waiting to get some more use. The system is set up with 7+ TB of storage that'd I'd love for you to fill up, and I can afford putting more hard drives in when it gets to that point. http://www.piqd.com/tarbackup_server.png
I think you must be quite surprised at the responses you're getting to your offer of a free gift. But some things are serious enough that them being free is a serious red flag.
In other words, I've you had presented this as a commercial offering in stead of as a hobby and just for fun you would have given a better first impression, one that proved that you had thought through the problem before embarking on solving it.
HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies.
You've solved none of the problems that tarsnap already solved and then on top of that you have added a whole pile of new ones. So I think that even though I applaud your generosity and your general approach that this is not going to go very far. Using 'tar' means you're targeting developers, most other people will have never even heard of tar other than that black sticky stuff. Developers know the value of their data better than anybody else does (or at least, they should) and they will evaluate a backup service based on that value.
> HN has been a pretty strong critic of the way tarsnap is being run (specifically from a marketing point of view), the collective view is not that it is too expensive but rather that it is not yet expensive enough and that it needs to appeal more to non-techies.
If that's the collective view, then I strongly disagree with the first half. Tarsnap isn't cheap for an organization with data of any appreciable size.
Most 'X' as a service concepts have a point where doing it yourself is the more cost efficient option. Backup is no exception to that rule. A service like this works best when you have a manageable amount of very precious data. If you have mountains of low grade data then likely you're better off rolling your own.
After all, since tarsnap is a very nice layer on top of S3 there is always at least one competitor cheaper for bulk back-up (amazon) and even they charge a substantial amount of money for storage and bandwidth.
Costs vs benefits. It's never been different and it never will be.
Wow, that's some serious hardware you got there. I think it's good that you are clear about this being a hobby thing: this helps people put a value on it (e.g. it's an extra backup, but not a replacement for a backup, as your house might burn down or something, just to name something crazy – this actually happened to me once).
Also did not see you posted the code already: cool!
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.
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.
You make some great points here, thanks for the feedback. The code for the server scripts is posted on git if you have any suggestions on the security end. http://www.github.com/nanch/tarbackup/
- how long will it be around: for the foreseeable future
- how I plan to stay alive in the long run: I don't see why the service would need to be shut down.
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.
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.
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?
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.
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.
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.
A few things that don't impress me right off the bat:
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).