Backblaze: to decrypt your backup, send us your private key passphrase
help.backblaze.com
help.backblaze.com
But the linked page is a long FAQ that seems reasonable after a cursory read. It's not the ideal setup for everyone, but they don't seem to be hiding anything.
What am I missing here?
Is there another well known service that does this completely right? (honest ask, not a challenge)
Edit: sounds like there isn't anything in their budget price range that does it well either. Sounds like it should be a goal to provide it, but hard to fault them too hard.
It's weird that they would go through all this other effort and then have this obvious fail right at the end. Sure, I understand convenience for, say, a web UI or a mobile interface maybe, but it's really odd that they wouldn't have implemented the obvious, client-side-only version first.
It's fully aimed at power-users though. I'm sure all of my family would be more secure on backblaze because they couldn't set up tarsnap right. For myself though, I use tarsnap.
Currently I only use it to back-up the non-huge parts of my home directory and /etc. This keeps costs reasonable to me.
I know these prices are pretty close to the actual cost of storage, which is amazon S3. I suppose backblaze can do better by handling their own storage.
I wouldn't want to be responsible for safeguarding the key to my own data if I could help it though. Or put another way: The whole reason I'm using cloud backup is because I can't be trusted with important data.
If this is not sufficient, then don't use the service. It's that simple
It's funny how they have to keep answering questions about this when this is not how they do stuff. They focus on easy of use.
If a person is not happy with the way they do stuff then they're free to GPG stuff and upload it to wherever they think is best.
You either use private keys that remain with the client, or you don't use asymmetric crypto in the first place. They're trying to mix security with convenience by eliminating the security aspect, leaving only convenience with a false sense of security.
Then, they would have to deal with the blowback there when the most common scenario where a restore is needed happens. A backblaze customer's drive is dead/wiped/whatever. Right when the user needs their files back, the same drive(s) that were lost also has the private key.
It seems like a reasonable solution given that constraint, and that their demographic is people wanting a cheap solution.
Security isn't pushed on their front page at all really. I'd agree with your comments if they were leading with a "super secure" message. Their setup appears secure other than restoral, and you get to make the choice at that point to weigh the risk. You also have the choice of not setting a pass phrase, but encrypting your own data before upload if you want.
Blackblaze would be able to bruteforce the passpharse but if a sufficiently expensive derivation algorithm is used then it would not be really feasible for anything but the simplest of passwords.
> A solution would be then to story copy of the key encrypted on their servers
This is what we do. If you set a private passphrase, then we are keeping your private encryption key for you encrypted with the passphrase on our servers. If you never prepare a restore (or up until you prepare your first restore), your files are unable to be read by malicious hackers that have compromised our systems (if that ever occurs), because you have literally never given us the passphrase. Or put differently, we could not possibly comply with a subpoena for your data because we cannot decrypt it, period.
> send you the key when you initiate recovery
This is the only part we do not do. Instead, when you provide the passphrase, we only store that passphrase in RAM on our server side for the minimum amount of time possible to decrypt the file or files you have requested, then we purge the passphrase from RAM. After you download the restored file we purge both the passphrase and the decrypted file from our systems and everything returns to the safest state again. Yes, this creates a short window of decreased security (can be as little as 60 seconds). But as long as we weren't compromised during that 60 seconds your data is and will stay totally encrypted. 99.999% of the time Backblaze has no ability to read your data. It is actually 100.0% of the time if you are using Backblaze as a Hail Mary offsite backup in case your house burns down and burns your local backup up. As long as your house never burns down, Backblaze will remain stoically there and encrypted and hackers or the government will have zero ability to ever read your data, period.
> It doesn't provide an additional layer of security to use asymmetric crypto the way they are using it.
I disagree. Here are some examples of where I think it has been useful to us (and our customers):
1) Backblaze encrypts the data with pub/priv keys and then sends the completely encrypted data over HTTPS. When OpenSSL had the Heartbleed bug, the HTTPS was not enough, and our encryption kept us safer for the few days until we had everything patched and fixed. So from time to time when SSL/HTTPS has zero day vulnerabilities, the extra layer of encryption helps.
2) If you set a private passphrase, it is literally a zero knowledge system until the first time you ever request a restore. Let's say you don't need a restore for two years. If a hacker penetrates our systems at any time during that two years, your backup is completely impossible to read, because you literally have never supplied the private pass phrase. Ok, so then after two years let's say you need one of your files back. At this point you hand us the private passphrase (which we do NOT write to a disk, it is stored in RAM only). Yes, at this moment there is a short window (maybe 60 seconds long) of decreased security until your backup is prepared and when you download it. Then we delete the plain text version of your files (all completely automated on a secure computer in our datacenter) and we purge the passphrase from RAM. Then after that window if at any point AFTER that our systems are compromised then you are totally safe because the hacker cannot roll back time and gain access to the past. Is this perfect? No. But 60 seconds of slightly decreased security on one computer in our datacenter is better than leaving your files laying around in original unencrypted form in our data center for YEARS.
What you're describing is certainly better than no encryption, but couldn't the system be designed so that unencrypted customer data is never accessible by Backblaze? That the decryption occurs only when a user enters the password locally?
I understand the vital convenience tradeoff of storing the private key. I might be willing to make that trade too if not for the various 'bleed vulnerabilities known and yet to be discovered, that threaten to disclose my passphrase to evil haXor$ when the time comes to transmit my passphrase to BB.
And when you combine those two concepts together, it really only leads me to the conclusion that this is defective by design in order to support surveillance requests. Even ones that can only be satisfied when the user types in their PEM passphrase. Prove me wrong by implementing that so-called "FINAL improvement" noted at the end of that KB entry.
There are many ways around that, none very elegant. They picked what they felt exposed the least amount of awkwardness. Only expose a flaw in the somewhat rare case of a restoral.
> they've shaved every other cost in their system to the bone to achieve a low cost product for the consumer
In addition to making sure you have a backup you can restore from, we always want Backblaze to be: 1) fast (low impact on your system performance), 2) easy, 3) inexpensive. You only focused on the inexpensive part. To be super easy, we need to be as easy as it is to sign into your Gmail account -> username and password and that is it. Then for the more security conscious (just like Gmail) we offer two factor authentication, and go even further than Gmail goes by providing the ability to set a private passphrase.
> their average customer is backing up data that's on the same drive that the keys would be on
This is correct. We could require the customers to remember their own private encryption key on a USB thumb drive and store it at their bank in a safety deposit box, but that would SEVERELY decrease the number of customers Backblaze has.
> this is defective by design in order to support surveillance requests.
Backblaze has never had a surveillance request. Plus, if you set a private passphrase we literally could not comply because we simply could not decrypt your data. We really, REALLY don't want to know what is in your backup and we take great pains to not know. Seriously, it is a liability to us to know what is in your backup. It is a liability to have the ability to decrypt your backup.
You can also check out our team at https://www.backblaze.com/company/team.html and ask around about us. We have been in the same 30 mile radius in Silicon Valley for 25 years (working at Apple computer, Silicon Graphics, HP, Oracle, GE, etc), and we have been doing online backup for ten years now. We take our customer privacy VERY seriously, and our personal reputations are extremely important to us. We are the good guys and we try our best to do right by our customers.
You are correct. There is a "window of decreased security" where IF there was a zero day hack on the same day you prepared a restore -> your data might be compromised.
> The passphrase should stay on my hardware period.
For some customers and some data, that is true. If you would PREFER to lose your data than to have even a 0.000001% chance of that data being read by hackers then I totally agree with you. A good example is if you will immediately be arrested and sent to jail for the rest of your life if the information in your files is ever discovered, then you should keep the passphrase on your hardware (or preferably only in your head and never written down).
But let's say the data is simply all your pictures of your dogs and your vacations? That type of customer might value increasing the chance of getting the data back over the ultimate security solution. Having a recoverable password lowers security (because anybody who gains access to your email can now access your data) but it increases the chance of data recovery. People forget passwords sometimes.
Different customers have different preferences, and Backblaze tries to offer several valid choices and let the customer decide which one to use.
By arguing the passphrase should be sent to BB servers, you're unnecessarily violating two fundamental principles of security, least access and least privilege.
> As you prepare a restore, you must type in your private passphrase into the restore server.
Seems like a pretty fundamental architecture fail here.
Later the site goes on to acknowledge this:
> We actually want to improve this to provide a password encrypted ZIP file for download, and then the FINAL improvement is to actually allow you to download the private encryption key, download the encrypted files, and provide the pass phrase in the privacy of your computer. We hope to add this functionality in the future.
Are they serious? Security conscious users a) still have to give up an encrypted copy of their private key, ripe for cracking, and b) they are supposed to download all their terrabytes of data in zip form, presumably over HTTP with no resume option?
Smh...
[1] https://help.backblaze.com/hc/en-us/articles/217665908-How-t...
* Unencrypted HTTP
And why is it that HTTP implies no resume (Range header has existed since HTTP 1.1 if I recall correctly)?
> Range header has existed since HTTP 1.1
Backblaze built the original zip restore functionality in 2007 and I believe the range header was introduced after that? We FULLY support the range header in our B2 Object Storage and we actually have support for it (now) in the ZIP file download functionality.
However, because we built the client side custom program bzdownloader (our restartable restore downloader) it seems to still succeed in some situations where a web browser doesn't succeed. We can slowly retire our custom bzdownloader application as all web browsers catch up and have restartable downloads.
This means the data is also secure in their datacentre at rest. That is, until you provide backblaze with your password to actually access your data.
Essentially, until you need the data that is backed-up, no-one can get to it.
Better to keep them offline and keep ownership of the key as a second factor certainly, but encrypted keys can be a fully acceptable single factor.
(said bug also caused me to exhaust my 1TB Comcast cap several months in a row, BackBlaze was unresponsive and unapologetic throughout the whole process)
AFAIK AES in CBC-mode is a no-no because it betrays which blocks of data are identical, and that's what BlackBlaze uses.
I really liked the fact that I could set my own key too.
There are some issues with CBC regarding the fact that it can't really be parralelized. It also lacks authentication as opposed to the newer GCM mode.
In general though, AES-256 CBC is essentially THE standard best practice proven form of encryption.
They have a lot of employees who read HN and I'm sure they're cool guys, but I think they really need to reconsider their performance in customer experience.
> Backblaze has repeatedly refused to add something as simple as pagination to their B2 web interface
Not "refused to add", it's on the list! We have a relatively small team of programmers (no VC funding, no deep pockets, we can only hire when we can afford it), and every week we meet and set priorities and the engineers work on the very highest priority stuff in order. The pagination has been delayed in favor of other features and bug fixes. I'm not saying we prioritized correctly, I'm just explaining why it has not been done yet.
> which most people would not dream of going live without
Part of the challenge (fun?) of building a business is the "build order". We don't make any money until we release the product, so as soon as we can justify it we released it in "paid beta" to collect feedback like yours and make some money which in turn allows us to hire one more programmer and build that feature for you.
If B2 doesn't fit your needs yet, my only request is that you come back every six months and check again, because it is always evolving.
But this has been "on the list" for about a year. For an object storage offering, crashing the tab whenever someone opens a large bucket is not something to brush off. I was initially sympathetic, but since B2 also does not have an API call that will allow me to update my filenames (either 'rename' or 'copy to new name') to comply with the "virtual folders" feature, which either didn't exist when I wrote my script or which I overlooked, I'm stuck.
I asked support to make a bigger push to get some simple pagination added and they said they'll register the feature request. I emphasized that this isn't just a convenience feature, but that it actually makes the tab too slow to use and/or crashes it (don't remember which right now to be honest), but it didn't matter. I asked support to make a one-time exception and find someone who could run a find and replace on the object filenames to comply with the new name structure and they declined to do so. The only option is to pay to download the incorrectly-named files and reupload under new names, which would cost a lot of money in download fees, not to mention a lot of clock time and bandwidth.
Of course, this isn't really intractable. To avoid extra charges from Backblaze, I could just upload the files again since I still have a local copy (for now), but that would also take a lot of time and bandwidth. I could write a client-side script that would stop the B2 interface's broken behavior, and that would make the bucket semi-browseable/usable via the web. But I just don't feel a need to do all that when I could use other solutions that are better about this kind of thing.
B2 left beta a while ago iirc.
"Web restore key access - You must supply your custom key in order to restore files"[1]
[1]http://support.code42.com/CrashPlan/4/Code42_App_Reference/S...
[1] https://support.crashplan.com/Restoring/Downloading_Files_Fr...
[2] http://thewirecutter.com/reviews/best-online-backup-service/
1) Online Backup ($5/month) where every file is encrypted on your laptop BEFORE being sent to Backblaze and your backup is secured by your username/password - where you can recover your password if you have access to your email account. (We support two-factor auth which provides an additional optional layer of protection.)
2) Online Backup ($5/month) where every file is encrypted on your laptop BEFORE being sent to Backblaze and your backup is secured by your username/password AND your private encryption key is secured by a "passphrase" that is not recoverable in any way, shape, or form. (Two-factor auth is also optional here.)
3) B2 Object storage (half of 1 cent/GByte/month) where you store your file completely unencrypted, and this can be "private" (only accessible by username/password) or "totally public accessible by knowing the URL". A good application of this is serving up a web page to the public - you really WANT people to see all the contents!
4) B2 Object storage (half of 1 cent/GByte/month) where Backblaze has zero knowledge. You cannot browse your file hierarchy because Backblaze doesn't know your filenames. You cannot preview your images. You cannot recover your passwords. There is no other option other than downloading the encrypted blobs and applying whatever decryption algorithm you decided on (we have no ability to know what that is).
Ok, so I think some (many?) people in the security field think that Backblaze should ONLY offer mode #4 (and maybe #3 to serve up public websites). I happen to disagree and I personally feel that products #1 and #2 are useful and appropriate for some customers. But everybody is welcome to their opinion and we want to be completely open as to what exactly is occurring and what we are offering as a service.
Personally I think #2 is an excellent trade off of security vs convenience. Your data is as impervious to attack as a zero knowledge system in #4 for years upon years. Then one day your laptop is stolen or crashes and you want your files back. You want all 4 TBytes back - so you order one of our free (encrypted) USB hard drives to be FedEx'ed to your home with all your data. To kick this process off FOR THE FIRST TIME EVER you tell us your passphrase (up until this very moment it really has been zero knowledge). At this moment you are opening a window of SLIGHTLY lowered security that slams shut after a few hours. For those few hours of preparing your 4 TByte restore, if an undetected hacker had compromised the one restore server in the Backblaze data center that your job was on, that hacker could possibly get access to your files. But then the reduced security window slams shut, we NEVER write your passphrase to any disk so it has now vaporized and we do not remember it, and if a hacker hacks into our system the following day you are STILL completely impervious.
But again, as long as you fully understand the implications of #3 I am COMPLETELY supportive if you instead choose #4 which is our "Zero Knowledge" offering.
When it comes to restore you have the users over a barrel - if they want their files back, they've got to pony up their passphrase. If they don't, their data is gone.
My parents could encrypt the stuff themselves using rclone or hashbackup, but they have no idea how to do that. So they use Jungle Disk with client-side encryption (and decryption) instead.
Question: I Don't Trust You, but I am Expecting an Honest Answer. "If I opt to password-protect my private key, are BackBlaze servers still able to decrypt my data? (For instance, by sending the password to the server where my private key is stored and decrypting the private key on the server) Or is my data only able to be decrypted on the client?"
Answer: ABSOLUTELY NOT. Once the password is set do not forget it, there is no way to recover it. Once protected by a private encryption key Backblaze can only decrypt the backup files when the user supplies the password. This is done during the restore process and the supplied password is never saved on our systems, although never to disk, only to RAM.
What it Comes Down to is Trust, but, Unfortunately, I Just Can't Trust You. "Having the private key outside my computer is unacceptable. The unfortunate thing is that I can't trust you. I'm not allowed to trust you. So, I guess my question is why do I have to? It makes most sense that I shouldn't -have- to trust you..."
I understand. What you are describing is conceptually perfect and provably more secure than what Backblaze provides , unfortunately it is not easy to use. Backblaze focuses on ease of use. It is backup for people who need backup and "pretty good security" and who aren't computer professionals. It is not a perfect choice for all users on earth, you are unfortunately outside our scope.
Take our default security model -> it is about as secure as a Facebook account. It uses a username and password. You can recover (reset) your password if you have access to your email. That mode is good for many, many people on earth, people who have pictures of their children they don't want to lose. Music they would rather not repurchase. And a few Quicken docs that they would not like a malicious person to have, but they will not DIE if somebody reads them. And it's SUPER convenient to recover their password. What a great system!
Our second level is really, really much more secure. You cannot recover the password to access to your email account does not give you access to the backup, and even a malicious hacker in our datacenter could not possibly compromise your data. Now while it is more secure, it is also harder to use -> if you forget that password you have actually lost the backup, your wedding photos are gone forever. That's very secure, but it's not as secure as what you describe.
We stand by our reputation as trustworthy, careful programmers who have worked in the security field for over a decade. You can check us out on LinkedIn, through colleagues that have worked with us, through the publicly traded companies that have acquired our companies in the past. Here is our team page: https://www.backblaze.com/team.html We live and work in Silicon Valley, we've been here for 20 years, and we plan to keep doing this for a long, long time, and therefore we have LOTS of interest in keeping our reputations rock solid and utterly clean. Previously we fought phishing fraud, fought email viruses, and fought spam at a company called MailFrontier. We are totally customer focused and all around good people, ask ANYBODY. If you come here to our offices, I'll buy you a cup of coffee.
I wrote the above information several years ago, and I'm still proud of the "I'll buy you a cup of coffee" line at the end. :-)
But we need to update that web page because we have expanded our offerings (mainly with the B2 Object Storage) and can offer customers more choices now.
This is one of those situations where security and convenience are diametrically opposed. If Backblaze doesn't keep a copy of your keyfile and you didn't complete steps B-D to make and keep a secure backup, you're screwed. Most consumers are better off trusting Backblaze to keep that data safe for them.
You could say that they should offer this as a secondary mode of operation, but then people would say "Yes, I want the most security possible! Yes!" and then they'd sing quite a different tune when they get their backups back and can't actually use them, and Backblaze already has enough problems with their customer service dept.
If you want full client-side encryption, use B2 and hook up something like duplicity to automatically difference and encrypt your files before you upload them.