It's not quite milliseconds. According to https://www.documentcloud.org/documents/1302613-ios-security... they've increased the iteration count somewhat:

“The passcode is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack. A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds.”

This is still an argument for using a longer length code, however, since a simple 4-digit number would only take 800 seconds to brute force.

This can't be true. If you restore your iCloud backup to a new device, all you need is your passcode. It obviously won't ask you to enter the UID of the device you previously backed up with.

You're not limited to 4 digits. In fact, when you set up Touch ID, the phone prompts you to enter a longer text-based passcode on the basis that you shouldn't have to enter it often.

The government has your fingerprint.

Which doesn't help them much because the fingerprint will only reveal the passcode if they gain physical access to the device's "secure element" and its contents (which is reportedly hard).

It is really surprising how much HN turns a blind eye to / lacks imagination for potential security issues just because it's Apple.

Well, actually it isn't surprising at all.

I'm inclined to reverse that. Whenever Apple tells the world about a way they're attempting to protect their users' privacy above and beyond what any other for-profit technology company of comparable size and scope has done, HN immediately tries to deconstruct it--which is by and large good, since we need to remember that no security model is perfect. But a small but vocal subset always demonstrates a remarkable level of imagination in presenting scenarios in which Apple can actively conspire against their users while remaining within the letter of their guarantee. I'm not positive this happens jut because it's Apple, but I have my suspicions.

You've got a lot of reasonable responses above.

I am certainly not "HN". If you want to argue/discuss, do so. I'm well aware that a "secure element" is never 100% unbreakable. But in the usecase the GP mentioned (government broadly gathers data), hiding the data in a separate hardware compartment will at least help.

I think it's just PR bullshit. Apple has been known to abuse the law. I'm sure some government gave them the green light to lie about this and have another backdoor.

My government doesn't have my fingerprint, but the US government does...

If you grew up in the US, they already have it. Every elementary school kid in the US gets fingerprinted.

EDIT: It appears I was wrong, this was only in LA county.

Uh, what? Neither I nor my children have had such an experience in public school.

Not the point. The point is that they've done enough to legally respond to government requests by saying "we don't have a way to access the data". Hacking customers' phones, regardless of how easy it might be, is far beyond the scope of anything that a US court can order a private party to do.

> is far beyond the scope of anything that a US court can order a private party to do.

They could order Apple to disclose signing keys so that the government can install spyware themselves. See http://en.wikipedia.org/wiki/Lavabit#Suspension_and_gag_orde... for a case where they have done something similar before.

>the government can install spyware themselves

It would have to be an OS update since applications don't have access to that stuff, even if signed with an apple key.

That's probably not quite true. Take an app that the user is already likely to have given access to their photos, like Facebook. Create a malicious app with the same app identifiers, sign, and push to the user. At that point, the phone thinks it's Facebook, and should allow access.

That said, it'd be kind of unsubtle, and they'd probably get caught.

Ahh yes, I assumed we were talking about messages.

I assumed it was primarily the review process ensuring that the proper sandbox configuration was included in the bundle and applied to apps at runtime, checking for private API use automatically etc, and that Apple could probably ignore their own restrictions if they chose to, especially those private APIs.

iOS won't let even the most permissively configured, "unreviewed" app do things that apps aren't supposed to be able to do?

But its something the NSA is more than capable of accomplishing

It is only protected with just the passcode when on the physical device - Apple cannot bruteforce it because they don't have the capability to access it remotely (they can only wipe it).

Is this still the case in iOS 8? I know it was the case previously, but has anything changed in iOS 8 to prevent apple from just brute forcing the 9999 combinations with a mounted flash drive?

There is a "self destruct" option to wipe the iPhone after 10 failed pass code attempts. It's not bulletproof against a bruit-force but it's something