3 ms·

The reason people are taken aback by their service is that if they're going to store the private key on the server, then they shouldn't even be using client-sid

The reason people are taken aback by their service is that if they're going to store the private key on the server, then they shouldn't even be using client-side encryption to send the backups in the first place. It doesn't provide an additional layer of security to use asymmetric crypto the way they are using it. So why do they have it at all? To make their service sound more secure than it really is. The service is essentially using false advertising to trick nontechnical users, and that is what turns people off. 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.

tyingq 9y ago
Some people are taken aback. I can see their dilemma. Lots of clients are probably backing up the same PC where the key would be if they used "private keys that remain with the client". 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.
- dogma1138 9y ago
  A solution would be then to story copy of the key encrypted on their servers and send you the key when you initiate recovery the KEK for that key will be derived from your pass phrase im the client only. 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.
  - brianwski 9y ago
    Brian from Backblaze here. > 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.
brianwski 9y ago
Brian from Backblaze here. > 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.
- zeroer 9y ago
  Hi Brian, I'm a happy Backblaze customer. Thanks for commenting. 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?

tyingq 9y ago

Some people are taken aback. I can see their dilemma. Lots of clients are probably backing up the same PC where the key would be if they used "private keys that remain with the client". 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.

dogma1138 9y ago
A solution would be then to story copy of the key encrypted on their servers and send you the key when you initiate recovery the KEK for that key will be derived from your pass phrase im the client only. 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.
- brianwski 9y ago
  Brian from Backblaze here. > 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.

brianwski 9y ago

Brian from Backblaze here. > 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.

zeroer 9y ago
Hi Brian, I'm a happy Backblaze customer. Thanks for commenting. 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?