"Enter your passcode to trust this computer and start a backup." Every time iPhone is on charge.

So in this scenario, this someone has hacked into the computer but doesn’t have root access and can’t run a sudo command to create the symlink? That seems like a pretty arbitrary scenario. The sudo password is the login password for most people, so how exactly are they hacking the computer? Your unshakable faith in Apple is… inspiring.

I have great faith in the technical skill of Apple’s engineers and security team. And I haven’t the slightest idea of your qualifications. But I have been working in Unix and Unix variants for over 40

• A computer backup uses a lot of storage; one backup of my phone is 25 GB, and that’s when I’m syncing photos to iCloud

That's for the first one. After that, they'll save only the changed data, not a memory dump, just like Time Machine. And in any case, that only matters if you're short of memory. And, the memory costs the same be it filled or empty.

sgucukoglu wrote:

Of course, iOS 16.2, with its vaunted new Advanced Data Protection for iCloud, nevertheless doesn't fix this issue for local backups. (ADP for iCloud is only available in the US at the moment, and I'm not in the US.)

Correct. Because the reason for it is to protect the backup copy of your phone on your computer from being hacked. It has nothing to do with your phone. It assures that only YOU can create a backup of your phone; not someone who has access to your computer or has hacked into your computer.

So as of this morning, the phone still asks for the password. But, when the computer asks you if you want to cancel or try again, if you select the cancel option, the backup continues normally to the completion of the backup.

Apparently, it's another case of the left hand and the right hand working in different departments.

JayGreenstein wrote:

So as of this morning, the phone still asks for the password. But, when the computer asks you if you want to cancel or try again, if you select the cancel option, the backup continues normally to the completion of the backup.

Apparently, it's another case of the left hand and the right hand working in different departments.

That doesn’t compromise the security, because it still requires a physical step by the user on the phone to initiate the backup, something that a remote hacker can’t do. But it is an interesting observation.

The guys from iMazing wrote a summary of the whole issue with this passcode prompt. They recommend that Apple enforces a passcode prompt only for unencrypted backups which makes total sense. I mean backup data could still be moved to an unprotected location, but since it's encrypted it's completely useless to the attacker.

john-berlin wrote:

The guys from iMazing wrote a summary of the whole issue with this passcode prompt. They recommend that Apple enforces a passcode prompt only for unencrypted backups which makes total sense. I mean backup data could still be moved to an unprotected location, but since it's encrypted it's completely useless to the attacker.

No, it really isn’t completely useless. Apple allows unlimited guesses for the backup password. So if you have the encrypted backup you can run an automated process that goes through all combinations of alphanumeric passwords until one unlocks the backup. While the encryption algorithm is a strong one that is essentially unbreakable, a brute force attack that simply guesses passwords at very high speed, perhaps using multiple processors, can decrypt the backup. This may not work for strong passwords (20 character random passwords, for example), but very few people use more than a 6 to 8 digit password, and those are easily broken using a brute forced attack. That’s how most password attacks work on stolen corporate databases.

Your argument would then basically apply to everything encrypted. If you are in possession of the encrypted data, you can always try brute force, sure. But by this logic you would need to declare everything encrypted insecure. Your encryption is always only as strong as your passphrase is.

Also you're probably mixing up two things. The passcode you use to unlock your device (the possibly 6 to 8 digit password you're talking about and the one this thread is about) is not the same as the one with which you decrypt your backups. It is a completely separate passphrase which you have to set up during your first backup. Apple could simply require stronger passphrases for this one if they wanted to make bruteforcing harder. And since it's not the same passcode you have to enter every time you take your phone out of your pocket, it wouldn't upset anyone.

john-berlin wrote:

Your argument would then basically apply to everything encrypted. If you are in possession of the encrypted data, you can always try brute force, sure. But by this logic you would need to declare everything encrypted insecure. Your encryption is always only as strong as your passphrase is.

Not true, because most encrypted data does NOT allow unlimited password attempts. For websites it usually locks after 3 or 4 failed attempts. For an iOS or Mac passcode it slows down at 6 attempts, and locks permanently after a few more. The fact that Apple allows unlimited attempts to guess the backup password is the true vulnerability, but they did that probably because enough people forget that they created a backup password, since it could have been years before. It only prompts for the password once, for the first encrypted backup.

The real problem for websites (and apps) is that if the server that the site runs on is hacked (which is VERY common; there have been hundreds just this year, and let’s not think about EquiFax in 2017 who had 120 million accounts stolen or the US Government Office of Personnel Management system hack of 2015) a brute force attack can be run on the downloaded passwords. That’s why there are stolen plaintext passwords and account IDs available for sale on the dark web. Want to see if yours has been hacked→https://haveibeenpwned.com/?

also you're probably mixing up two things. The passcode you use to unlock your device (the possibly 6 to 8 digit password you're talking about and the one this thread is about) is not the same as the one with which you decrypt your backups. It is a completely separate passphrase which you have to set up during your first backup. Apple could simply require stronger passphrases for this one if they wanted to make bruteforcing harder. And since it's not the same passcode you have to enter every time you take your phone out of your pocket, it wouldn't upset anyone.

I’m not mixing up anything. The backup password is not the same as the iPhone screen passcode (which is 4 or 6 digits, never 8)* OR the Apple ID password unless you make them the same. But it is just another password, probably 6-8 characters chosen by most people. And so far, in trying to help people unlock their encrypted backup, I’ve never encountered anyone who used the same password for their Apple ID or their screen passcode as their backup password.

*iOS allows you to choose an arbitrary length screen unlock passcode, but I suspect the number of people who choose that option can be countered on the thumbs of one hand. Although some devices under MDM do require it.

Not true, because most encrypted data does NOT allow unlimited password attempts. For websites it usually locks after 3 or 4 failed attempts.

That's why I wrote you need to be in possession of the encrypted data. Then you always have unlimited password attempts since there is no service in front that will limit this. You try to apply the AES decryption on the data itself rather than talking to a decryption service of some kind in front. By its nature you can do this forever without anything stopping you.

The whole CVE was about gaining access to the backup data, an attacker moving the backup data to an unprotected location in his control. This obviously becomes an issue with unencrypted backups. If you choose a weak password for your backups then of course this also might be problematic for encrypted backups. The above mentioned unlimited brute forcing possibilities will then make it easy to crack the password.

But you cannot take away everyone's ability to have automatic backups just because you assume everyone is using weak passwords. If this is really Apple's concern they could just implement strong password requirements during backup setup. That's all I'm saying.

john-berlin wrote:

Not true, because most encrypted data does NOT allow unlimited password attempts. For websites it usually locks after 3 or 4 failed attempts.

That's why I wrote you need to be in possession of the encrypted data. Then you always have unlimited password attempts since there is no service in front that will limit this. You try to apply the AES decryption on the data itself rather than talking to a decryption service of some kind in front. By its nature you can do this forever without anything stopping you.

The whole CVE was about gaining access to the backup data, an attacker moving the backup data to an unprotected location in his control. This obviously becomes an issue with unencrypted backups. If you choose a weak password for your backups then of course this also might be problematic for encrypted backups. The above mentioned unlimited brute forcing possibilities will then make it easy to crack the password.

But you cannot take away everyone's ability to have automatic backups just because you assume everyone is using weak passwords. If this is really Apple's concern they could just implement strong password requirements during backup setup. That's all I'm saying.

I agree with your last paragraph. But I think the real solution is to solve the problem on the computer end rather than the phone. As an educated guess I’m thinking that this is a temporary workaround until they can develop and test a secure way to prevent backups from being relocated on the Mac or PC. The guy that discovered this flaw ranted about Apple’s approach to solving it, saying the problem should be addressed at the computer end.

It's still alien language to me, besides a commercial reason from Apple, why I have to type a PIN (not even the face to unlock my telephone) every time I am uploading a backup (not a trojan virus) from my telephone to my computer (not a network or a loaner, etc), which previously had to be recognized as "trusted" and I also entered the password to my apple id. By the way, my backup has been encrypted for some years. It is beyond common sense anyone defending the idea the PIN previous to back up, due to alien invasion or anything like that. Have you guys and gals realized that for the back up in icloud the pin is not required? Can anyone put 2 and 2 together and realize that Apple just want everybody (or increase) the number of people paying for cloud space to do backups? I hope Apple realizes that before massive attritions from iphone to samsung.