3 ms·

I don't understand why BackBlaze would decrypt on their premises rather than offload that processing to the client computer. I mean they've shaved every other c

I don't understand why BackBlaze would decrypt on their premises rather than offload that processing to the client computer. I mean they've shaved every other cost in their system to the bone to achieve a low cost product for the consumer, but the one area where the rubber meets the road, they chose to incur the cost of decryption. 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.

tyingq 9y ago
My guess is that their average customer is backing up data that's on the same drive that the keys would be on. Such that the keys would be lost in the same event that would have the customer wanting a restore . 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.
- brianwski 9y ago
  Brian from Backblaze here. > 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 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.
  - CodeWriter23 9y ago
    You will be able to comply with a surveillance request WHEN a customer has to restore. Also, you've done nothing to address the risk eavesdropping due to 'bleed style exploits while transmitting my passphrase to BB servers. The passphrase should stay on my hardware period.
    - brianwski 9y ago
      > address the risk eavesdropping due to 'bleed style exploits while transmitting my passphrase to BB servers 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.
      - CodeWriter23 9y ago
        You're really conflating issues. Yes, Store the Passphrase-protected private key on your server. No, do not send my passphrase to your server for a restore. Yes, send the private key to my client. No, do not decrypt my data server side. Yes decrypt it client side after I enter my passphrase into my client. No, don't transmit my passphrase anywhere at all. By arguing the passphrase should be sent to BB servers, you're unnecessarily violating two fundamental principles of security, least access and least privilege.

tyingq 9y ago

My guess is that their average customer is backing up data that's on the same drive that the keys would be on. Such that the keys would be lost in the same event that would have the customer wanting a restore . 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.

brianwski 9y ago
Brian from Backblaze here. > 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 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.
- CodeWriter23 9y ago
  You will be able to comply with a surveillance request WHEN a customer has to restore. Also, you've done nothing to address the risk eavesdropping due to 'bleed style exploits while transmitting my passphrase to BB servers. The passphrase should stay on my hardware period.
  - brianwski 9y ago
    > address the risk eavesdropping due to 'bleed style exploits while transmitting my passphrase to BB servers 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.
    - CodeWriter23 9y ago
      You're really conflating issues. Yes, Store the Passphrase-protected private key on your server. No, do not send my passphrase to your server for a restore. Yes, send the private key to my client. No, do not decrypt my data server side. Yes decrypt it client side after I enter my passphrase into my client. No, don't transmit my passphrase anywhere at all. By arguing the passphrase should be sent to BB servers, you're unnecessarily violating two fundamental principles of security, least access and least privilege.