I am touched you saved my email and remembered me, and that at the time you didn't respond negatively to the message. Thank you for being a customer.
The only thing I regret is that comment about version number of 2.3.1 and the claim that it would run flawlessly for a decade. Oh geez, please upgrade to 8.0.1, you won't regret it.
-- Brian Wilson, CTO Backblaze, brianw@backblaze.com
e.g. https://www.reddit.com/r/backblaze/comments/jsrqoz/personal_...
It seems that they may be changing their tune, at least as of a few months ago: https://www.reddit.com/r/backblaze/comments/m3xynu/backblaze...
The current limit is 50 characters. There are reasons we don't let it get super long like 2,000 characters but we could easily double or triple the maximum length it if it was requested. Is there a number of characters you have in mind? I found a chart here: https://i.imgur.com/trR2u8g.jpg that says a randomly generated 17 character password would take 93 trillion years to crack. The chart doesn't even go up to 50 characters. Backblaze also supports 2-factor authentication via SMS or Google Authenticator codes which personally I would highly recommend to customers also.
> who knows what kind of encryption you guys are using
Backblaze has two product lines: "Backblaze Backup" where we wrote the app that encrypts data on your laptop before uploading into our storage cloud, and "Backblaze B2" where you use any third party tool (or write your own) so the encryption in that case is all under your control. You can see a list of 3rd party tools here: https://www.backblaze.com/b2/integrations.html (make sure you scroll down). There are little pictures of penguins by the software that supports Linux, little pictures of an apple for software that support Macintosh, and a little Window icon for the software that support Windows.
For "Backblaze Backup", we use a well known design where we use symmetric AES-128 to encrypt the file, but each file is encrypted with a different AES-128 key, and that key and an Initialization Vector (IV) is then encrypted by a 2048 bit RSA public/private key. You can read about the encryption flow we use in this blog post: https://www.backblaze.com/blog/how-to-make-strong-encryption...
>The current limit is 50 characters. There are reasons we don't let it get super long like 2,000 characters but we could easily double or triple the maximum length it if it was requested. Is there a number of characters you have in mind? I found a chart here: https://i.imgur.com/trR2u8g.jpg that says a randomly generated 17 character password would take 93 trillion years to crack.
Usually the reason people want longer "password" options is because they're using a diceware style pass phrase of 4-6 randomly generated words. It's not so much about ultimate security as many people having trouble memorizing decent fully random passwords. Key stretching and multifactor helps further of course. Longest normal English words are something like 21 characters before getting into niche science terms, so very conservatively 160 characters is probably going to fit even an extremely conservative edge case passphrase. That'd be 8x of some of the very longest words (unlikely to be randomly chosen) and match a 128-bit key which is plenty [0].
>* Backblaze also supports 2-factor authentication via SMS or Google Authenticator codes which personally I would highly recommend to customers also.*
I hope you'll consider adding (via Webauthn online or OS or other toolkits to the application) standalone hardware token support (like Yubikeys or Nitrokeys). Those are enormously more secure, convenient, and also have the bonus of eliminating another set of 3rd party dependencies. If you looked at those in the past and skipped them due to lack of device support worth looking again, every major platform should have coverage at this point.
----
0: Also, rather then thinking in terms of "years to crack" which inherently depends on the processor power thrown at it, might be better off considering in terms of combinations (or entropy). A standard symmetric key at this point is 256 bits, which means 2^256 combinations, but with stretching 128 bits is probably a very very safe seed for the password component. So that could be a "password" of [01] 128 characters long. That'd be roughly equivalent to [0-9] 38 characters long, or alphanumeric cased (26*2+10=62) 22 characters long. Current Oxford English dictionary edition I think has around 170000 words. If we figure a diceware program throws out ultra short, ultra long, and ultra weird words for convenience (whole point is something people can remember) so maybe it's cut down to the 70000 most common words >3 characters, that'd take 8. At a more typical 4-6 words, equivalent to maybe a 17 character cased alphanumeric password.
Gotcha. I'll file a Jira ticket to see if we can easily and quickly raise it to 200 characters (round number). I think we can handle that easily and safely.
> standalone hardware token support (like Yubikeys or Nitrokeys).
I'll run the idea by a few groups and see what people say. For feature requests NOT related to security, traditionally it's kind of a customer voting system. If enough customers want a certain feature it sorts to the top of the priority list and gets done sooner.
For security things it is obviously different, like if a big exploit like Heartbleed is released in the world we drop everything else and focus on that.
This is sort of somewhere in the middle, it's security related so it gets some additional boost up the priority list for that, but it's also a security feature not all customers would choose to use, so it is still affected by whether our sales and support teams are hearing requests for it.
Thanks so much for the reply, and yeah that's done-forever territory. Even "just" tripling to 150 as you earlier suggested would almost certainly be plenty, into pathologic edge cases.
>I'll run the idea by a few groups and see what people say. For feature requests NOT related to security, traditionally it's kind of a customer voting system. If enough customers want a certain feature it sorts to the top of the priority list and gets done sooner.
>For security things it is obviously different, like if a big exploit like Heartbleed is released in the world we drop everything else and focus on that.
Sensible way to do it. And yeah I agree this is kind of a hybrid of both. It's not a flaw per se, but it's more than a feature enhancement as there are genuine security implications. If you haven't looked into it, there have been cases of SMS hijacking for example, you can find plenty of discussions on HN alone with a quick "sms hijack" search. It's better than nothing but SMS infra just is fundamentally not very secure. One time tokens with a seed are better, but less convenient or secure then a blackbox that can enforce operator presence requirements or at least completely sequester keys.
Even a couple of years ago it would have been more annoying to integrate but the standards are progressing well enough now that it's probably worth another look. Adoption of hardware keys in business also finally seems to be hitting critical mass, though if we're in an S-curve at last this time around it's well before the steep slope.
Anyway, thanks again and best of luck with everything! As it happens plan to link up a new TrueNAS installation with B2 starting tonight :).