The PBKDF2 stuff is still there for the keybag, someone just added additional encryption (of the "file" column in that database - data that was previously unencrypted) with the same password using single iteration sha1.

(Data source: writing my own code to decrypt the backups about a month ago, or rather adapting my previous implementation to the new backup format.)

That will be a fun "git blame" (or equivalent) to make

Wonder how did that slip through

I didn't know we can brute-force SHA256 in a lifetime, yet.

Is it already possible?...

Essentially, your backups are encrypted with a key that is generated using a key derivation function (KDF), which takes in your password and outputs a "hash" that is fed into the encryption algorithm.

It's obviously much faster to brute force SHA256(dictionary_word) than a 128-bit key.

Apple was previously using 10,000 rounds of SHA-1 (with PBKDF1) as a KDF. This is much slower than one round of SHA-2 they've switched to by orders of magnitude.

ANY standard hash function (SHA256, SHA512, even SHA3) used to obfuscate a password can easily be brute forced if the password has low entropy (like BigBlue8 or s3cr3tp4ssw0rd). These passwords are weak and hash functions are designed to be fast to compute, so it's possible to brute force them.

To brute force successfully SHA256, you don't necessarily need to brute force 2^256 possibilities, you need to brute force a much smaller list of likely passwords, and this might just be enough.

You can easily bruteforce against a dictionary. They're getting 6 million passwords/sec checked. Not enough to get an arbitrary hash, though.

If you only try the passwords that people are likely to use then... Yes

Would using a bunch of previous password leaks to create a rainbow table be useful for programs that do this? With the number of leaks it seems like it would be a pretty accurate depiction of how a lot of people choose passwords.

Yes. However, rainbow tables are trivially mitigated with a random salt, which requires you to regenerate your table for every hash.

I don't know if iTunes uses a salt to encrypt the backup.

Forgive my ignorance on the matter, but is this being handled by iTunes or by the Phone for encrypting the backups? Which element is actually at fault for the poorly protected backups?

If it's just iTunes being crappy with iOS 10 backups, then reasonably this is an easy patch, correct? And the change is perhaps a bit more understandable (trying to improve performance of actions from the already bloated iTunes); it's not a good reason at all to weaken the encryption method, but it at least provides a plausible explanation that doesn't have government interests as an impetus.

I also suspect this is on the iTunes side.

Maybe it is time to take a step back and question to what extent it is wise to trust iTunes. Could the encryption not be handled on the device? Then when the PC/Mac is compromised the backup would be still safe.

Well, it could be done on the device, but doesn't iTunes need unencrypted access to the device to function normally?

(Though perhaps it ought not to.)

It can't be iTunes' fault only. You're able to extract the data from the devices by sending the right commands, therefore the device is vulnerable.

Not necessarily. The article mentions phones being paired with iTunes - I assume this involves entering the passcode on the phone (haven't used iTunes for my phone in years, so I'm not entirely sure, but by my understanding of the iOS security architecture, it wouldn't be possible otherwise). This probably results in some sort of authentication token that iTunes stores and uses to get the device to perform backups. So yes, there's a command to extract data, but it's not unauthenticated or anything like that.

If iTunes has a token to get complete access to the device, and this attack requires access to that token, then again it's not an iTunes issue.

The way the article is worded makes me think that you wouldn't normally be able to use the token to get the data without this bug, which means that it can't be an iTunes issue.

Also, the fact that it's only iOS 10 implies the same.

Good point, that makes more sense.

It's a good question

If it's only related to iTunes then why does it only apply to iOS10?

Whaooo wtf? It is password 101 to use a password hash function to hash a password. This seems a very serious bug, by developers who ought know what they are doing :(

The other cynical person would say that doesn't make sense because out of the very small amount of people that backup via iTunes, an extremely small percent of them would actually bother encrypting.

If you don't encrypt the backup, then iTunes does not backup your stored passwords (wifi WPA2, web, mail, etc), health data, and other items considered "sensitive", which makes for a poor backup/restore experience. So there's a big benefit in enabling encryption in iTunes.

It's a bit annoying considering macOS can also use FileVault for full-disk encryption, which helps if the machine is locked/off. I guess it doesn't help against your macOS user account being compromised via a browser or anything.

Makes me wonder if anyone has taken a fresh new look at the FDE passphrase algorithms in macOS 10.12...

Or, also pessimistically, that they know more about Intel's

https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...

and its potential.