Hacker News new | past | comments | ask | show | jobs | submit login

Some technical detail would be nice. At the moment, this is just an advertisement for their iPhone backup cracking software.



Per Thorsheim says: "Apple have moved from pbkdf2(sha1) with 10K iterations to a plain sha256 hash with a single iteration only. Bruteforce with CPU!" https://twitter.com/thorsheim/status/779207177416351744


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 cynical pessimist would say they did this on purpose to help government agencies extract data.


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.


For me, Manifest.db inside the backup is a sqlite3 database containing a table Properties with two rows, salt and passwordHash, satisfying:

    passwordHash == SHA256(password || salt)


If you are encrypting data, why would you store a hash of the key at all?


Debug code that made it into production is the only thing I can think of, and even that isn't a good explanation.


yup, literally anyone could claim that.. bad article


Elcomsoft is hardly "anyone" when it comes to this particular subject matter. You may want to look them up.


That sounds close to an appeal to authority.


It's not the logical fallacy you think it is when there's an actual authority involved.


Appeal to authority requires an actual authority to be involved.


And it's not a fallacy

> An argument from authority (Latin: argumentum ad verecundiam), also called an appeal to authority, is a common type of argument which can be fallacious, such as when an authority is cited on a topic outside their area of expertise or when the authority cited is not a true expert.

https://en.m.wikipedia.org/wiki/Argument_from_authority

Calling it a fallacy when there's an actual authority is the part that's incorrect. It's no longer a fallacy when the appeal to authority (argument from authority) involves an actual authority.


> It's no longer a fallacy when the appeal to authority (argument from authority) involves an actual authority.

If I have to go google who has written that article to blindly believe in it - that certainly reflects poorly on the article itself.


Why would you do that? The citations are there for a reason.

Several reasons. One of which would be to avoid using the article author's background as part of an argument against the content of the article. Because that would be an ad hominem.


No, that's not true.

Appeal to authority means accepting what an authority says on the merit of the entity being an authority, and not on the validity of the statement itself.

Re-read your wikipedia article...


Yes, it is true. I said the instance wasn't a fallacy. Read my comment again. To be clear: an appeal to authority isn't always fallacious.


This part of what you said:

"It's no longer a fallacy when the appeal to authority (argument from authority) involves an actual authority."

is not true.

The right thing to say would have been "It is no longer a fallacy when the authority making the claim provides enough convincing evidence to make the claim valid, with or without an authority", if that's indeed what you meant to say.

But that's not what you said, and so I stand by my assertion that what you said is not true.

We have the original post in this thread of interest saying (paraphrasing): "The article has no substance, so the claim is it making could be made by anyone. The article is not useful and the claim is not substantiated".

Then we have a reply: "Elcomsoft is an authority on the topic so their claim should be stronger than if anyone else made it".

This is where I said it looks close to an appeal to authority.

But you then came in and said "when there's an actual authority there is no longer an appeal to authority".

Which is not true.

I mean, how can there be an appeal to authority with no authority? That's like saying there's a car accident with no car.


They did not just write an article, they also provide the brute forcing tool to prove their claims.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: