3 ms·
While I do agree that private keys and transparency is important, I feel they almost need to store the private keys as well. But they should be password protect
by foldor 12y ago
While I do agree that private keys and transparency is important, I feel they almost need to store the private keys as well. But they should be password protected by something only the user knows, and the password shouldn't need to be transmitted over to their servers.
The reason they would need the private keys should be obvious. They are a data disaster recovery service. In the event of a disaster where all of your drives fail, or are inaccessible you would still need access to your data. So if the only copy of the private key isn't on their servers you would be shit out of luck, not exactly a good situation for a company like theirs.
But yeah, store the private key, but make it encrypted by a secure password only decrypted locally, and update documentation to make this clear.
- twoodfin 12y agoBut yeah, store the private key, but make it encrypted by a secure password only decrypted locally, and update documentation to make this clear. I think even this is "too secure". I forget my 'secure passwords' regularly, and I'm sure I wouldn't be the only one. It's not a huge improvement over telling a user to print out a private key and keep it somewhere safe. Given the likely threats to Backblaze, I'd encrypt user backup private keys with a threshold or other multi-key scheme. No individual Backblaze employee's key would be sufficient to decrypt a backup; you'd need the active participation (and private knowledge) of at least a few. That prevents individuals from snooping, and requires compromising several employees to decrypt backup data.
- gh02t 12y agoIncidentally, if anybody is looking for a way to set up keys like twoodfin is describing, you might want to look at ssss. It's an implementation of Shamir's secret sharing scheme and works quite nicely for me. http://point-at-infinity.org/ssss/ http://point-at-infinity.org/ssss/