Need help with deciding on a new external desktop drive

[Anjin San]

i haven’t clicked on that yet, but this theme is why i’m not super keen on backblaze’s “you can’t choose, we back up ‘everything’”. i don’t want it putting my passwords and such on the cloud, for example

BB lets you choose drives to backup or not. You can choose particular file types to ignore but that’s difficult. However…as long as you select the encrypted backup option and choose a sufficiently long password, mine is 40 or so characters in a sentence with all 4 of the password food groups…everything is encrypted before it leaves your computer and essentially uncrackable. If you use Apple devices and the iCloud system…a lot of sensitive stuff is in the cloud…but the6 take care to keep it secure. The truth is that for the vast, vast majority of us…the expense of trying to crack the encryption just isn’t worth it…not to mention that with a 40 character encryption key even if the bad guy gets your password file…the ncryption makes it basically impossible to decrypt the file…and then say it was 5our 1Password file…the bad guy even after breaking the BB encryption still has to deal with the 1Password encryption. TLDR…This isn’t something you need to worry about as long as adequate passwords are used…and in 2024 that doesn’t mean gibberish, it means long and sufficiently memorable to you that it is easy to type accurately. For instance…4 common dictionary words each with 1 capital letter, separated by the same symbol or a different symbol that only you know the pattern of, and some random digits on the end that again meet a pattern only you know is plenty complex enough. In theory…a completely gibberish password of the same length is mathematically ’better’…but in reality the difference in security between a billion billion centuries to crack and 1.1 billion billion centuries is completely irrelevant.

The security of my encrypted cloud backups is not even on my list of concerns…math and length are your friend here.

Source…I did computer security for a living the last 15 years I worked…and length is your friend here.

 

[Anjin San]

I was seriously unimpressed by this article. "If your backup account is hacked, your data may be vulnerable." Why yes, that is kinda true.

To which I'd add, If your brokerage account or bank account is hacked, your money is vulnerable. If your healthcare provider is hacked, your medical information is vulnerable. If a major credit report agency is hacked (hey wait, that happened ...) all your credit history and details around that history are vulnerable. If your machine is infected by malware, everything on it may be vulnerable. And email ... if your email account is hacked, is there anything in those emails of interest to a hacker?

The better backup services encrypt your data at rest and during transmission. Some will allow you to provide a key that *they do not retain*. So hacking the backup provider won't get you anything except a bunch of files protected with state of the art encryption. Of course, if only you know the key, should you lose/forget the key your data on the backup servers cannot be retrieved.

The article also extols the virtues of password managers, which I agree with; password managers are great and much better than the alternatives. Alas, if your password manager gets successfully hacked... well, that's bad since now all your accounts and passwords are vulnerable, conveniently organized in one place. If I were interesting in hacking, I would be targeting password managers and financial accounts, credit reporting agencies , etc. Hacking individual cloud backups seems like a poor use of hacker time; sifting through, in my case, about 5 TB of data the vast majority of which is not valuable, to try and get ONE person's data. Versus going after financial institutions, etc, where the percent of interesting information is much higher.

The threat to my data is much less from my cloud backups than from many many other things. Take for example the Equifax breach in 2017. Nothing you as a consumer could have done to prevent that hack.

Me either…as I said in the other reply…BB can use a separate encryption password besides the login password for the BB account…and that password is algorithmically combined to fully encrypt the data before it leaves your computer…so even if BB is hacked and the baddies get your encrypted blob of data…it is still encrypted…and a sufficiently long password ensures that *only* brute force try every password cracking attempts can be used…and the guess must be 100% correct or the cracking software gets a No answer…even if 39 of the 40 characters were actually correct. There is no ‘close’ in cracking passwords…the guess is either right…or wrong. Today…mid 20s in length is more than sufficient as long as one includes both cases, digits, and symbols…and increasing the length by a single character adds many orders of magnitude to the potential number of guesses required. Go check out grc.com/haystack.htm…Steve Gibson’s page does the how hard is it math for you…and it doesn’t need to be gibberish…for instance the password “I like cold beer Every Day except Sunday&&&123” is just as good as gibberish of the same length for any practical purpose (it is actually not quite as good…but the difference is negligible compared to the how long to crack it time).

 

[jerrylwatson]

I agree a long password is needed. Correct me if I am wrong. If a cloud sotage service is hacked they don't need the passwords. They just need to decrypt the encrypted data which is all of users of the service.

 

[PhotoLover]

I agree a long password is needed. Correct me if I am wrong. If a cloud sotage service is hacked they don't need the passwords. They just need to decrypt the encrypted data which is all of users of the service.

As Anjin San worked in security he knows more about this than I do (I worked in software, but not security) but the short answer to your question is completely no in some situations. As both of us mentioned, you have the option with many backup services to provide a key that is NOT kept on the backup service servers. In that case, even if somebody hacked the backup service, all they would get is a bunch of encrypted files; the backup service does not have the key to decrypt.

Also, to be clear, each backup client will have a different key for their data. What I do not know is just how secure the backup service is if you have not elected to keep the key only on your machine (i.e. the backup service can access the key, so they can assist you if it is lost). In that case, it seems possible that a hack could secure access to your data on their servers and the key to decrypt. I'll note again this seems like a high effort/low yield way for a hacker to gain access to financially useful information.

 

[jerrylwatson]

As Anjin San worked in security he knows more about this than I do (I worked in software, but not security) but the short answer to your question is completely no in some situations. As both of us mentioned, you have the option with many backup services to provide a key that is NOT kept on the backup service servers. In that case, even if somebody hacked the backup service, all they would get is a bunch of encrypted files; the backup service does not have the key to decrypt.

Also, to be clear, each backup client will have a different key for their data. What I do not know is just how secure the backup service is if you have not elected to keep the key only on your machine (i.e. the backup service can access the key, so they can assist you if it is lost). In that case, it seems possible that a hack could secure access to your data on their servers and the key to decrypt. I'll note again this seems like a high effort/low yield way for a hacker to gain access to financially useful information.

How can it be "completely no" and your reply says nothing about password.

 

[PhotoLover]

How can it be "completely no" and your reply says nothing about password.

You said "they don't need the password." The password != to the key used to decrypt.

You need a password (I'm working off what I do on a backup service that is not backblaze) to log into your account and in my case onto the app. But that password will not decrypt the data. A separate key is used to decrypt the data.

Again, with my service, you can let the service generate the key and store it. Or you can supply a key that only you know; it is not resident on any machine on the backup provider. If the latter, it doesn't matter if they know your password or not, they can hack into the backup service and copy your files but they can't decrypt the data because they don't have the key. If you have elected to use the vendor supplied key, then (this is where I think you'd need to know the details of how a given service works) potentially someone could hack the service, and presumably if they could get user account details -- like the key -- they could copy user X's data and use the key associated with that account to decrypt that data. They would not necessarily need a given user's password to successfully hack the service provider and get user(s) account information. If the attack is to the vendor's backend software, individual user account passwords are probably irrelevant to the success of the hack; the user is not being attacked, the vendor is.

But sure, if the backup service is providing the encryption key and a hacker gets *your* password then presumably they could log into your account and download and decrypt your files (or if they know the key you provided and your password). I think this is more or less the same risk as you have of your bank account getting hacked, etc.

 

[jerrylwatson]

You said "they don't need the password." The password != to the key used to decrypt.

You need a password (I'm working off what I do on a backup service that is not backblaze) to log into your account and in my case onto the app. But that password will not decrypt the data. A separate key is used to decrypt the data.

Again, with my service, you can let the service generate the key and store it. Or you can supply a key that only you know; it is not resident on any machine on the backup provider. If the latter, it doesn't matter if they know your password or not, they can hack into the backup service and copy your files but they can't decrypt the data because they don't have the key. If you have elected to use the vendor supplied key, then (this is where I think you'd need to know the details of how a given service works) potentially someone could hack the service, and presumably if they could get user account details -- like the key -- they could copy user X's data and use the key associated with that account to decrypt that data. They would not necessarily need a given user's password to successfully hack the service provider and get user(s) account information. If the attack is to the vendor's backend software, individual user account passwords are probably irrelevant to the success of the hack; the user is not being attacked, the vendor is.

But sure, if the backup service is providing the encryption key and a hacker gets *your* password then presumably they could log into your account and download and decrypt your files (or if they know your key and your password). I think this is more or less the same risk as you have of your bank account getting hacked, etc.

Again, I am not talking about hacking your account, but hacking the service with all accounts. In that case the encryption key is needed, not your account password. The password is not used to encrypt/decrypt the data but rather a key is used for individuals data..

 

[PhotoLover]

Again, I am not talking about hacking your account, but hacking the service with all accounts. In that case the encryption key is needed, not your account password. The password is not used to encrypt/decrypt the data but rather a key is used for individuals data..

Right, that's what I was saying. And the key needed is per user, and may or may not be stored on the service's machines, depending on how the user account is setup.

So I'm not sure what question/comment you were making above; I must be not understanding your question.

 

[jerrylwatson]

Right, that's what I was saying. And the key needed is per user, and may or may not be stored on the service's machines, depending on how the user account is setup.

So I'm not sure what question/comment you were making above; I must be not understanding your question.

It was just a statement that the account password does not protect the data if the service is hacked.

 

[Viathelens]

I was seriously unimpressed by this article. "If your backup account is hacked, your data may be vulnerable." Why yes, that is kinda true.

To which I'd add, If your brokerage account or bank account is hacked, your money is vulnerable. If your healthcare provider is hacked, your medical information is vulnerable. If a major credit report agency is hacked (hey wait, that happened ...) all your credit history and details around that history are vulnerable. If your machine is infected by malware, everything on it may be vulnerable. And email ... if your email account is hacked, is there anything in those emails of interest to a hacker?

The better backup services encrypt your data at rest and during transmission. Some will allow you to provide a key that *they do not retain*. So hacking the backup provider won't get you anything except a bunch of files protected with state of the art encryption. Of course, if only you know the key, should you lose/forget the key your data on the backup servers cannot be retrieved.

The article also extols the virtues of password managers, which I agree with; password managers are great and much better than the alternatives. Alas, if your password manager gets successfully hacked... well, that's bad since now all your accounts and passwords are vulnerable, conveniently organized in one place. If I were interesting in hacking, I would be targeting password managers and financial accounts, credit reporting agencies , etc. Hacking individual cloud backups seems like a poor use of hacker time; sifting through, in my case, about 5 TB of data the vast majority of which is not valuable, to try and get ONE person's data. Versus going after financial institutions, etc, where the percent of interesting information is much higher.

The threat to my data is much less from my cloud backups than from many many other things. Take for example the Equifax breach in 2017. Nothing you as a consumer could have done to prevent that hack.

I just got my Honda repaired at the dealer and they were working with paper only as they were hacked last week. I was told 15,000 dealers use the software and the hack included information on new car buyers, which contains data that hackers want. They had no clue when the system would be back up. It's just what happens in the world of today.

 

[PhotoLover]

It was just a statement that the account password does not protect the data if the service is hacked.

Ah, okay, I was reacting to this:

They just need to decrypt the encrypted data which is all of users of the service.

and remarking that the key is per user, not shared across all users of the service (which may not be what you meant but I wasn't sure), AND that the service may not actually have the key on their servers at all, in which case hacking the service still doesn't get your data.

 

[PhotoLover]

I just got my Honda repaired at the dealer and they were working with paper only as they were hacked last week. I was told 15,000 dealers use the software and the hack included information on new car buyers, which contains data that hackers want. They had no clue when the system would be back up. It's just what happens in the world of today.

I sorta gave up when they hacked Experion. Think of all the data on people they got there. SSNs, mutliple addresses, listing of all financial accounts, etc etc. You protect yourself as best you can.