3 ms·

Of course, but it's not like other providers offer this ability already "baked in". At the same time, Backblaze only offers a security-theatre for encryption -

Of course, but it's not like other providers offer this ability already "baked in". At the same time, Backblaze only offers a security-theatre for encryption - they give you the ability to encrypt your backup private key with a password before sending it to them. But during restore, they collect this password and decrypt everything server-side. What's the point of offering encryption then?

jdlshore 5y ago
Because security isn’t black and white. If you’re going to use BackBlaze’s software, which has access to all your files, you have to trust Backblaze as a company. If you don’t trust them, don’t use their service. Simple. There is no circumstance under which you can both distrust them and run their software. (Try tarsnap instead.) So now the question becomes: what threats are you protecting yourself against? For me, it’s: - malicious employees accessing my data - a security breach giving outside actors access to my data. Encrypting the backups and encrypting the private key protects me against these threats. My “restores” aren’t protected against these threats, because they’re not encrypted (as of 2019 when this FAQ was written), so that’s a gap. It’s one I’m willing to put up with because I can mitigate the risk by not leaving restores hanging around.
- red0point 5y ago
  You’re saying that security isn‘t black and white, but trust somehow is, which I find a bit weird, since they‘re intimately related. Backblaze could easily reduce the trust required, which they‘re not doing, but have been promising to do for years, with nothing happening. Also, given your threat model, I‘d say the risk-mitigation is not applicable. Attackers lying low and continuously collecting and exfiltrating data is nothing new. Especially if this data includes passwords, private keys and data „zipping-by“. Or does your threat model include specifically only an attacker being advanced enough to compromise Backblaze, but somehow not being able to persist for a while? No, it‘s Backblaze‘s job of keeping data safe the best way possible, it shouldn‘t be necessary for customers to find excuses for their bad encryption scheme or to add another layer of encryption, especially if the fix is quite obvious and has been promised for years.

jdlshore 5y ago

Because security isn’t black and white. If you’re going to use BackBlaze’s software, which has access to all your files, you have to trust Backblaze as a company. If you don’t trust them, don’t use their service. Simple. There is no circumstance under which you can both distrust them and run their software. (Try tarsnap instead.) So now the question becomes: what threats are you protecting yourself against? For me, it’s: - malicious employees accessing my data - a security breach giving outside actors access to my data. Encrypting the backups and encrypting the private key protects me against these threats. My “restores” aren’t protected against these threats, because they’re not encrypted (as of 2019 when this FAQ was written), so that’s a gap. It’s one I’m willing to put up with because I can mitigate the risk by not leaving restores hanging around.

red0point 5y ago
You’re saying that security isn‘t black and white, but trust somehow is, which I find a bit weird, since they‘re intimately related. Backblaze could easily reduce the trust required, which they‘re not doing, but have been promising to do for years, with nothing happening. Also, given your threat model, I‘d say the risk-mitigation is not applicable. Attackers lying low and continuously collecting and exfiltrating data is nothing new. Especially if this data includes passwords, private keys and data „zipping-by“. Or does your threat model include specifically only an attacker being advanced enough to compromise Backblaze, but somehow not being able to persist for a while? No, it‘s Backblaze‘s job of keeping data safe the best way possible, it shouldn‘t be necessary for customers to find excuses for their bad encryption scheme or to add another layer of encryption, especially if the fix is quite obvious and has been promised for years.