31–40 of 64 posts
>Will you backup my Backup VPS?
> Unfortunately, no. Even though we use a RAID protected setup, there is still a slight chance of data loss due to RAID controller failure. For extreme redundancy you can order 2 backup VPS in different nodes and we can mirror them for you ("Configure it for me" addon should be purchased).
Earlier quoted context omitted.
I've looked into this before and concluded it was possible, although I forget exactly how. I bookmarked https://crypton.io/ and http://peerjs.com/ . PeerJS is p2p WebRTC, which I believe I chose because I wanted to do secure, real-time p2p file sharing. That isn't 100% relevant for this, but downloading the file over some socket into client-memory then decoding it there sounds like something webrtc could be a good op…
It's a really interesting idea (and sounds really fun to build) but a bad idea from a security perspective. Javascript crypto in the browser just doesn't make sense[1]. Summary of the link: Since you trust the server to serve the JS files, you might as well trust it to do the decryption and present it all over SSL. > I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doe…
The main issue here is that your Javascript can potentially be owned by XSS or other approaches. If you own the javascript, you can send plaintext passwords or keys (which should have only been available to the client) back up to some server.
Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files. The author makes a good point in saying that you download javascript on each request, which makes it more susceptible to getting owned than a native-app, but I think a successful attack with this approach will still be an order of magnitude less severe than if an attacker owned a server full of unencrypted data. If the data is unencrypted, an attacker that manages to own the server has access to everyone's data. With it encrypted, the attacker will only get data from users who are using the site while it's owned.
Isn't that still a better option?
You have to trust the VPS provider.
I can still follow this guide to create my online-NAS box and use it across devices.
I'd never heard of Backupsy before, looks very cool! What is special about their VPS offering that makes it so cheap? I mean, from what I can see for an extra $2/month they let you host websites and install anything you want (except torrents, TOR or anything illegal). I've been wanting to have an affordable VPS solution so I could be host my own stuff, and have the freedom to experiment with various development tools…
However as you can see from the SLA (99.9%), you do have to pay something in the form of reduced redundancy and availability. If, for example, an HP RAID card freaks out and all the VM's get corrupted on your blade, well you are out of luck. That data is gone forever. It's a small risk, but it is a real one (in fact with the P410 they are using, that's actually happened to me before in production). There are lots of other things that can go wrong too. Virtualization is not all rainbows and unicorns.
In the end I think it's still a good deal if you need a backup target with phat storage in it. But if you are interested in just trying out stuff, I think Digital Ocean is a better call since they have a higher SLA (99.99%) and probably a better dashboard and it's around the same price. Backupsy, as the name implies, is made for backups.
I wonder if this is really usable like Dropbox. I tried owncloud which is supposed to be the more stable alternative but it kept replacing new files with old ones, sync took ages and security was weak. I really want to support this kind of projects but they hold me from being productive, which I really need right now.
The correct solution involves using FSEvents (which blows), and system poling when you get an event. Inotify is good enough to get away with no poling. The native windows change watcher isn't bad either.
Even if this weren't the case, the value that dropbox provides is far greater than this potential solution for most people- ie, there is quite a bit of room for something to go wrong running your own duct tape dropbox. Syncing 99/100 files is not OK. Syncing 100/100 files, but only after 2 weeks isn't OK either.
source: I built my own ducktape dropbox (sortof). https://github.com/Floobits/flegmatic
Are people looking at bitTorrent Sync? ( http://labs.bittorrent.com/experiments/sync.html ) I'm uing it on a laptop, a server and my android devices. It works great. Seemless.
Closed source is a dealbreaker for lots of people.
Earlier quoted context omitted.
It's a really interesting idea (and sounds really fun to build) but a bad idea from a security perspective. Javascript crypto in the browser just doesn't make sense[1]. Summary of the link: Since you trust the server to serve the JS files, you might as well trust it to do the decryption and present it all over SSL. > I think the biggest thing someone who tackles this needs to realize is that perfecting the crypto doe…
Err I don't think this would stop me. But let me preface this by saying I learn something new about security quite frequently, so if there's a major premise I'm missing, I am both interested in learning about it and not completely surprised. The main issue here is that your Javascript can potentially be owned by XSS or other approaches. If you own the javascript, you can send plaintext passwords or keys (which should…
On the contrary go right ahead. Learning through doing is the way to go. I'm just saying there's a big difference between testing/learning/prototyping and releasing something that is claimed to be secure. Otherwise you end up with Cryptocat[1].
> Even with that possibility though, I still think using browser-based crypto creates a more secure environment than the server storing unencrypted files.
If you're using any JS then you have to completely trust the server that is serving it. At any point the server could replace "good.js" with "bad.js" and the browser will happily execute it. Any encryption you perform on the client side would be moot as "bad.js" could do whatever it wants with your plaintext and your encryption keys.
> If the data is unencrypted, an attacker that manages to own the server has access to everyone's data. With it encrypted, the attacker will only get data from users who are using the site while it's owned.
Again you're trusting the server to not save your encryption keys though by serving you "good.js" and not "bad.js"! All roads lead back to you trusting the server to play nice.
Unless you use untrusted remote services as opaque object stores and handle all encryption via secure code on the client side with proper signatures to prevent remote tampering[2], you're trusting the server not to compromise you.
[1]: http://en.wikipedia.org/wiki/Cryptocat#Security_concerns
[2]: Tarsnap (https://www.tarsnap.com/) is a perfect example of a client not trusting the server. The tarsnap service stores it's data on S3 but first all data is encrypted client side on your own machine. From the tarsnap service's perspective it's just storing a bunch of random binary blobs and that's all your client sends/recieves. Encryption/decryption happens locally on your machine.
$ ssh-copy-id encbox@your.vps.com
I'd never heard of Backupsy before, looks very cool! What is special about their VPS offering that makes it so cheap? I mean, from what I can see for an extra $2/month they let you host websites and install anything you want (except torrents, TOR or anything illegal). I've been wanting to have an affordable VPS solution so I could be host my own stuff, and have the freedom to experiment with various development tools…
There is nothing particularly special about Backupsy as far as I can see. Just cheap simple servers with a bunch of disks in them. This type of hardware is very cheap. The software layer is equally simple - seems like just KVM and a dashboard, nothing fancy. So then low cost, low price right. Good combo. However as you can see from the SLA (99.9%), you do have to pay something in the form of reduced redundancy and av…