Hacker News Reader

Comment by ikeboy | Hacker News Reader

>The digital world is very different from the physical world. In the physical world you can destroy something and it’s gone. But in the digital world, the technique, once created, could be used over and over again, on any number of devices.

They leave out the fact that Apple would need to sign (literally, using their private key) every time it is used.

>Unfortunately, we learned that while the attacker’s iPhone was in FBI custody the Apple ID password associated with the phone was changed. Changing this password meant the phone could no longer access iCloud services.

Why can't Apple change the password back, reset the flag that says the password was changed, and have them turn it on again?

View on HN

They don't really leave it out of the equation, though they don't explicitly state how it factors in. The issue is that a high profile case that people want to be prosecuted to the fullest extent is being used as a wedge to force a large undertaking (producing the unsecure firmware) to be made. Future requests from law enforcement on much smaller cases would then only require the smaller undertaking (signing the existing firmware), and resisting that court order would be significantly more difficult.

If the court decides that they're obligated to comply, then that should apply in all similar cases. Resisting that order would be more difficult because they already lost the battle, not because they already created the tool.

My point is that it would also apply in a smaller cases for a different reason than simple precedent: it would require no significant work not already undertaken.

This is the crux.

But why would that be bad? It shouldn't require significant additional work, even in smaller cases. If the FBI is getting warrants to access things without actual probable cause, then we need to be outraged about that issue, not how they get access.

It really seems like you've argued against yourself with this.

You are assuming the password is the key to authenticating. It might be, but it also might be that there's a two way handshake that sets up an encryption key for transmission of backups in a somewhat similar manner to how PFS works with SSL.

Whatever it was, changing the Apple ID password changes something on Apple's servers, and if they have the old state they can change it back.

The only two obstacles I see is if

1. Apple deletes info from their server on password reset 2. The phone was on, and already received the message not to try to sync anymore because of the password change

Both seem unlikely but possible.

You missed the entire point of my post. If I was designing a protocol I intended to be secure, I would add code that would fail if the password was changed and then changed back. I'm not saying Apple did this, but it's entirely possible they did.

How would the phone know that the password was changed if it was off the whole time?

Either 1 or 2 must be true for my proposal to fail.

It hasn't been off, that's been established already.

Where?

Just speculating, but if they changed the password using a "forgot my password" email verification method, then there may no longer be any record of what the old password was.

But then the data was on Apple's servers, and could possibly be recovered with data recovery. Also, I doubt Apple deletes that when there's no need to.

I know Google stores previous passwords, and will alert you if you try logging in with a previous password.

Deleted comment

Hashes or whatever. The point is they have the ability to tell if I typed in an old password, so they must store some form of it somewhere.

Reply on news.ycombinator.com