Apple Refutes Hacker's Claim He Could Break iPhone Passcode Limit (cnet.com)

A security researcher claimed he had figured out a way to bypass the passcode lock limit on an iPhone or iPad, ZDNet reported. But it turned out the passcodes he tested weren't always counted. From a report: "The recent report about a passcode bypass on iPhone was in error, and a result of incorrect testing," Apple said Saturday in an emailed statement. Since the 2014 release of iOS 8, all iPhones and iPads have come with device encryption protected by a four- or six-digit passcode. If the wrong passcode is entered too many times, the device gets wiped, explained ZDNet's Zack Whittaker. But Hacker House co-founder Matthew Hickey figured out a way "to bypass the 10-time limit and enter as many codes as he wants -- even on iOS 11.3," Whittaker wrote.

Comments

He was holding it wrong

[volodymyrbiryuk]

The recent report about a passcode bypass on iPhone was in error, and a result of incorrect testing

He was using/holding it wrong.

Re:He was holding it wrong

[Anonymous Coward]

So we're still doing this 10 years later? It has all the timeliness and terminal cancer humor of a Samantha Cee joke.

Re:He was holding it wrong

[Anonymous Coward]

Jobs was a rude, mean, greedy, smelly, narcissistic asshole. He deserves mockery.

Re:He was holding it wrong

[Anonymous Coward]

Or maybe they'd say he was hacking it wrong.

Re:He was holding it wrong

[Anonymous Coward]

Its still hilarious to those not blissfully in the walled garden.

Re:He was holding it wrong

[radarskiy]

So what you're saying is that Android has the same problem.

Re:He was holding it wrong

[Anonymous Coward]

So what you're saying is that Android has the same problem.

No, of course not - Android has no "wipe phone when too many bad passcode are entered" feature.

Re:He was holding it wrong

[BronsCon]

I mean, version 1.0 didn't;, then again neither did iOS. Both do now, though.

Re:He was holding it wrong

[Anonymous Coward]

Yep, the SOB, who was a millionaire, was too goddamned cheap to buy a fucking license tag.

Impossibru!

[Anonymous Coward]

It's a hacker, and therefore able to do ANYTHING! Or so the idiot's narrative goes.

Anyhow it's the daily "I wish I was a hacker"-routine by msmash. Nope, still nothing. You remain a poser forever.

I know how this turns out!

[Anonymous Coward]

It starts with either one of:

"Hold my beer..."
  or
"Challenge accepted..."

and one party being handed their ass.

Wipe phone??

[Anonymous Coward]

So I can wipe someone's phone without their consent? Is this a feature or a bug?

Re:Wipe phone??

[Anonymous Coward]

So I can wipe someone's phone without their consent? Is this a feature or a bug?

Well, yes. Of course after 5 attempts you have to wait an increasing time before another attempt - so all you have to do is type in 10 wrong passcodes spread unevenly over 3 hours.

Re:Wipe phone??

[jellomizer]

Hey, no trying to use reasonable facts to get us off our irrational hate Apple Rant. We need to feel good about our Android Phones, sure Android has its own problems, but gosh darn it! Apple is evil ... EVIL!

Re:Wipe phone??

[Immerman]

>So I can wipe someone's phone without their consent? Is this a feature or a bug?
A feature, obviously. That's what lets you repair a hopelessly borked device.

Physical access to the device voids virtually all security on any electronic device - the best you can hope for is to keep the new owner from accessing existing data on the device (which Apple does fairly well). Guess what - anyone with physical access to your laptop, desktop, flash drive, phone, tablet, etc. can do the exact same thing, and do so far more quickly and easily than by attempting to log in with an invalid password several times over the course of a few hours.

Re:Wipe phone??

[BronsCon]

So you've never taken your eyes off your phone for more than 3 hours at a time? Say, while sleeping?

Re:Wipe phone??

[F.Ultra]

I would assume that the people who enable it (yes you have to enable it) have made a decision that the risk of having the phone accidentally wiped is less than the risk of the information on it getting leaked. There is also this odd thing called backups that you can do which will severely lessen the problem of a deliberate wipe.

Re:Wipe phone??

[BronsCon]

Now there's a reasonable argument. You see, the one I replied to was not.

Re:Wipe phone??

[Anonymous Coward]

Trying so very, very hard.

Please let me know which chems make that possible, I've been eyeballing the nootropics fad.

Re:Wipe phone??

[Anonymous Coward]

So you've never taken your eyes off your phone for more than 3 hours at a time? Say, while sleeping?

Well, you just admitted above that you can wipe an Android in far less time, so sleep well with one eye open.

Re:Wipe phone??

[BronsCon]

I did? Where?

Re:Wipe phone??

[porlryan]

Rotten to the core you might say.

Re:Wipe phone??

[Anonymous Coward]

Irrational hate of Apple is as impossible as irrational hate of Stalin

I had a similar problem

[aepervius]

When entered your pin to unlock the SIm, if you enter more than 5 time it is supposed to sim lock you and ask for the PUK, but I could enter it as many time as I want and i was never locked. That was iphone 3 though.

Re:I had a similar problem

[Anonymous Coward]

This cannot have anything to do with the phone. The PIN is verified and eventually blocked by the SIM card itself, the phone only submits the PIN to the card as provided and has no way to know if it is correct or not until the card responds. That is unless it caches a succesful PIN entry and then verifies subsequent PIN entries autonomously without submitting them to the card. That would be a crazy thing to do and certainly not a bug but a deliberate backdoor (not to mention that you could have changed the PIN in the meantime using another phone) .

Re:I had a similar problem

[SharpFang]

Did entering the correct PIN unlock the phone?

'cause I'd be unsurprised if upon entering the correct PIN you got the same 'wrong PIN', authors of the phone just being lazy and implementing 'SIM doesn't work without PIN, ask for PIN regardless of lockout status'.

Re:I had a similar problem

[mysidia]

caches a succesful PIN entry and then verifies subsequent PIN entries autonomously without submitting them to the card

They might do this to improve login performance due to the SIM card having a slow response time ---
cache the user's correct PIN and verify it locally before submitting to the card, but if a SIM card change is
detected then expunge the cache.

Re:I had a similar problem

[BronsCon]

And if the sim card is removed, PIN changed on another phone, and SIM card is reinserted, all while the phone is off? SIM change not detected.

Re:I had a similar problem

[Anonymous Coward]

That would be asinine. The PIN remains authenticated until the the SIM is reset or the UICC applet is deselected on the SmartCard (but the phone should not want to do this normally). Authenticating requires sending 1 APDU and from a human point of view that happens instantly. The phone needs to interact with the UICC a lot more to authenticate with the network every now and then and that is much slower (the Milenage algorithm is computed fast since AES is hw-accelarted on SmartCards, but PIN verification is still way faster).

In exchange for shaving off a few milli- or even microseconds on boot you get to worry about a cache to invalidate and storing and keeping secure sensitive data.

Re:I had a similar problem

[Anonymous Coward]

cache in memory does not survive power off?

Re:I had a similar problem

[BronsCon]

Phone requires a reboot if the SIM is removed and reinserted, before it will read the SIM; if we were talking about cache in RAM, this conversation wouldn't be happening.

Re:I had a similar problem

[mysidia]

If the SIM was plugged into another phone and then modified and saved with a new PIN, then the result of the
SIM Status and READ commands which the phone can check prior to PIN authentication to retrieve the base files
on the SIM filesystem will no longer be matching files, if the cached data includes their checksum and/or
SIM status information, and the CCID and Update timestamps; they will reflect that some update has
been written to the card, and the phone could be designed to expunge the cache in this case.

Re:I had a similar problem

[BronsCon]

Somehow, it just doesn't seem that secure to hint at your contents prior to authentications. You sure that's how it works?

Re:I had a similar problem

[mysidia]

Somehow, it just doesn't seem that secure to hint at your contents prior to authentications. You sure that's how it works?

The PIN is used only to gain authorization required to perform management operations on the card's secure applications or to perform cryptographic operations using the secure keypair from write-only key storage in order to prove the user's identity to the network.

The SIM card's Status can be queried and the files and contents of the SIM filesystem, The names and Phone numbers of any contacts stored on the card, etc. Are not encrypted or locked by the PIN and could technically be read in without even authenticating ---- that's just ancillary information available on the card which is separate from the Network Identity and cryptographic material that the SIM card is designed to secure.

Re:I had a similar problem

[BronsCon]

good information; so updating only the PIN leaves visible traces elsewhere on the card? still seems like bad design.

6 months - 2 years..

[Daemonik]

In 6 months to 2 years Apple will admit, quietly, that this was all completely true and will roll out a repair program to fix the problem.

Re:6 months - 2 years..

[Anonymous Coward]

a quietly slow down your phone in the process.

Re:6 months - 2 years..

[jon3k]

It's fascinating to see how Slashdot has changed. Not that I agree with parents post (I don't) but a low 6 digit UID slamming Apple used to get a +5 Insightful or at least a +5 Funny.

Re:6 months - 2 years..

[Daemonik]

RIght? It's not even like Apple hasn't demonstrated exactly the behavior I pointed out before either. BendGate, KeyboardGate, AntennaeGate, BatteryGate. All instances where Apple shouted to high heaven the perfection of their devices then slowly had to walk it back after mass customer disillusionment and evidence they couldn't avoid.

Re:6 months - 2 years..

[Daemonik]

Oh, and when they do come up with a fix, it will require an Apple Certified PIN Repair Pro certificate that doesn't exist, and parts they haven't ordered into their supply chain.

Re:6 months - 2 years..

[Anonymous Coward]

RIght? It's not even like Apple hasn't demonstrated exactly the behavior I pointed out before either. BendGate, KeyboardGate, AntennaeGate, BatteryGate. All instances where Apple shouted to high heaven the perfection of their devices then slowly had to walk it back after mass customer disillusionment and evidence they couldn't avoid.

I have a theory that people making up new somethinggate words are immature twenty something year old men with inferiority complexes.

Re:6 months - 2 years..

[Anonymous Coward]

Dont forget GPUgate

Re:6 months - 2 years..

[Anonymous Coward]

Gategate

Re:6 months - 2 years..

[shaitand]

Yup. Slashdot has obviously been taken over and since people who actually understand technology don't use Apple solutions... lets just say it may be time to move on.

Re:6 months - 2 years..

[jon3k]

Didn't we already put "BendGate" to bed? The iPhone 6 Plus wasn't even the least likely to bend of the tested phones.

I don't remmeber Apple "shouting to the high heavens" about "KeyboardGate" (I assume the current keyboard problem?) or "BatteryGate" (not sure what this is? The performance throttling to stop the phone from shutting off?). AntennaGate I'm assuming is the "you're holding it wrong" and I'm with you on that one, my recollection of that was a huge PR mess for Apple with lots of blaming the user.

Re:6 months - 2 years..

[BronsCon]

Having been hit by KeyboardGate, I implore you to apply that theory to me. Even if we say I'm 29, the upper end of your assertion for that to be true I would have to have been 12 when I joined Slashdot after lurking for 4 years, starting at age 8. If you go back to my early posts (I'm not sure it's even possible to go back that far, I can only seem to go as far back as the end of 2008 for post history; my UID dates my account, though), you'll note that they were likely not written by a 12 year old.

Since one of your baseless assertions is clearly incorrect, it would be reasonable to assume that the other two are equally incorrect, as they are equally baseless.

One might also infer projection.

Re:6 months - 2 years..

[BronsCon]

We did, until Apple documents came to light showing that they knew the phones bent too easily.

Re:6 months - 2 years..

[jon3k]

The company found that the iPhone 6 is 3.3 times more likely to bend than the iPhone 5s, and the iPhone 6 Plus is 7.2 times more likely to bend than the iPhone 5s, according to the documents.

But being more likely to bend isn't necessarily a problem. The Macbook Air is more likely to bend than a Macbook Pro, but that doesn't make it a failure or poor engineering. Materials and engineering choices are made all the time. Every company chooses a particular level their device will bend or break at. In the iPhone 6 they choose to make a larger device, thinner, and were wlling to accept that it was more likely to break, assuming it is still within reasonable tolerances. Which is what Consumer Reports found, that it wasn't more likely to bend than other premium phones from other manufacturers. Just because it now wasn't 5x or 7x better than the competition doesn't make it a poor product.

But for some reason people seem to hold Apple to some higher standard of quality, usually while simultaneously complaining about how poor quality their products are.

Re:6 months - 2 years..

[BronsCon]

What Consumer Reports found is that it wasn't more likely to bend than other premium phones when pressure was applied in the specific way Consumer Reports tested the device. Where the two disagree (and they do), you can be fairly certain that Apple's testing was more thorough and correct than CR's, and should tend to favor that. I can pick out flaws in CR's testing, but I'll give you a big one right out of the gate: their results are the opposite of Apple's, with the 6 being more likely to bend than the 6 Plus.

Somebody got it wrong, and my money is on the company with a decades-long history of flubbing these sorts of tests.

But for some reason people seem to hold Apple to some higher standard of quality,

Probably because the company itself, along with its group of obnoxious fanbois, insist that they have always met that standard, and that they still do today.

usually while simultaneously complaining about how poor quality their products are.

Probably because quality is relative and a lower-middle-tier product that would be perfectly acceptable if that's what you had paid fo and expected to get becomes complete crap when it's advertised and priced as high-end. Think about it: nobody complains when their $20 pair of Wal Mart shoes only lasts a year; everybody would be bitching if that were true of a $200 pair, though.

Go look at some objective side-by-side comparisons of Apple and non-Apple laptops sometime. Look at the best Apple has to offer vs the best LeNovo or Dell has to offer, and tell me you still think Apple isn't junk for the price. Do they compare to the lower-middle-end of the typical PC manufacturer's range? Sure; but they're not sold as that and they cost considerably more than that. That's why it's a problem.

Sent from my 2016 MacBook Pro which, thankfully, isn't having keyboard issues this week.

urgk

[cascadingstylesheet]

What an unclear story. At first read, it sounds like Apple is saying "well, it's just that some of them don't get counted, so neener neener", which is, er, exactly what the guy was alleging.

If I understand the clarifications, what Apple meant was that some of them don't get used at all (to try to unlock the device).

Re:urgk

[Anonymous Coward]

What an unclear story. At first read, it sounds like Apple is saying "well, it's just that some of them don't get counted, so neener neener", which is, er, exactly what the guy was alleging.

If I understand the clarifications, what Apple meant was that some of them don't get used at all (to try to unlock the device).

Well, It's actually that Apple said pretty much nothing but "nope" - that "don't get counted" comes from the retraction from the hacker.

Re:urgk

[Anonymous Coward]

From TFA:

But Hickey tweeted later Saturday that not all tested passcodes "go to the [secure enclave processor] in some instances -- due to pocket dialing [or] overly fast inputs -- so although it 'looks' like pins are being tested they aren't always sent and so they don't count, the devices register less counts than visible."
And in a message to Whittaker Saturday, Hickey added: "I went back to double check all code and testing ... When I sent codes to the phone, it appears that 20 or more are entered but in reality its only ever sending four or five pins to be checked."

So it sounds like they were sending enough PINs to trigger the limit but the iPhone was only checking a subset of them which wasn't large enough to trigger it.

Re:urgk

[Anonymous Coward]

They can claim that, but watch the video he tweeted

https://twitter.com/hackerfantastic/status/1010240042990596096

It looks pretty clearly to my like the iphone responded with 11 failed attempts. 11 times in a row, you can see the 6 dots (representing the digits) fill up and then the phone buzzed indicating a failed attempt and the dots all cleared. On the 12th time, it unlocked.

So are they claiming the phone just pretended to try some of them without actually trying them, thus the user could have actually entered the correct code but the phone would have "rejected" it (gave the user the visual/vibration feedback indicating that it didn't work) without even actually trying?

Re:urgk

[Junta]

Basically he was cramming in a lot of digits into a keyboard buffer, but the phone didn't even think about most of them. Meaning that even if he guessed the correct pin, it's most likely it wouldn't have worked because it would be discarded without checking.

Re:urgk

[Anonymous Coward]

They can claim that

They can?

Sure! But then we can claim that the Moon is made of green cheese!

Re:urgk

[cascadingstylesheet]

Basically he was cramming in a lot of digits into a keyboard buffer, but the phone didn't even think about most of them. Meaning that even if he guessed the correct pin, it's most likely it wouldn't have worked because it would be discarded without checking.

Yes. My point was, that wasn't super clear from how this was reported.

While I'm nitpicking ... Apple didn't "refute" this either ... they denied it. "Refuting" would involve presenting some sort of proof, not just saying "you're wrong; check your work".

(Though I notice that Google has now added a second meaning of simply "deny or contradict" ... lovely.)

Re:urgk

[Anonymous Coward]

Google Moon used to show high-red imagery of the moon proving that it was indeed made of cheese. But the NSA made them remove that imagery and so Google is now a part of the conspiracy, too!

Re:urgk

[NoNonAlphaCharsHere]

Fucking Apple can't even handle a simple buffer overrun properly. If it were a Microsoft product it would have allowed remote arbitrary code execution with administrator privilege.

Re: urgk

[UnknowingFool]

You mean it was an unclear summary. The story itself lays it out: the hacker said there is a way to send a stream of passcode attempts via cable to the iPhone which would override the 10 attempt limit. He later had to admit is that the method he used did not always send the attempt correctly to the phone and it was ignored thus not hitting the limit. He thought he sent 20 attempts when reality it was 5 or 6.

Re:urgk

[Khyber]

"Though I notice that Google has now added [google.com] a second meaning of simply "deny or contradict" ... lovely."

Looking at a copy of my 1980s Random House dictionary from my old elementary school, the second definition of "refute" includes "To deny or contradict a statement or suggestion."

Looks like both you and Google are well behind the times.

Re:urgk

[Anonymous Coward]

They can claim that, but watch the video he tweeted

https://twitter.com/hackerfantastic/status/1010240042990596096

It looks pretty clearly to my like the iphone responded with 11 failed attempts.

Looks can be deceiving - and the description of the video on Vimeo seems to have been changed:

Apple iOS “Erase data” UI glitch

IOS has a glitch in the UI when pins are sent as duplicates or too quickly, to prevent accidental pin entry these pins are never tested by the device. This video showed what was original believed to be a bypass exploit for the erase data function, however the SEP is not actually processing the majority of the input PIN's due to the aforementioned feature in IOS. So although the device appears to process multiple pins sent at once, it in fact only processes a smaller number of inputs. This means the bypass attack isn't valid as it only appears that those pins were tested.

Re:urgk

[cascadingstylesheet]

Looks like both you and Google are well behind the times.

I sincerely hope so. Following the times on every stupid change is kind of ... stupid.

"Refute" in its most common usage was very useful; it meant essentially "to publicly dispute something conclusively, with convincing evidence".

Now people use it to mean simply "dispute", which is not nearly as useful.

Re: urgk

[UnknowingFool]

In the article the hacker admits that in reviewing his hack it appears that not all the attempts were received and processed by the phone. He says out of the 20 attempts, the phone may have actually got 5 or 6. This is not Apple saying it. This is the hacker.

Re:urgk

[Anonymous Coward]

Rebut

Re:urgk

[Anonymous Coward]

I guess you could just multiply the list of inputs to be tried, if the hardware is "supposed" to drop some of them, then with time, I suppose it would have gone through most if not all of the various inputs anyway. Maybe the added inconvenience of some inputs dropped, could be some kind of simple way of stopping people that run one single list? Then NSA/FBI would just run a longer list of inputs with duplicate inputs?

Am I understanding things correctly?

Re:urgk

[Junta]

I think it's not that it's "supposed" drop anything, it's just that he was injecting the data faster than any human could, and it *looking* like it was being accepted, but in reality it just fell on the floor.

There may be some incorrect technical behavior or just an expected limitation of the input, but either way it doesn't matter for normal use because it's way faster than a human would ever input data.

Re:urgk

[Anonymous Coward]

I am implying that this might be a back door!

I wonder, what if you had a list so long, it repeated a basic list, over and over again, and then presumably it doesn't matter if the iPhone drops/dropped just some of the entries, when what the article seem to say,you could feed the iPhone a continuous stream of entries as long as they are bunched up in one big stream. I can at least imagine a backdoor being hidden this way.

A "normal" hacker might fail because he only use a single list, while some government agency might have a prepared list of entries that are multiplied and maybe quasi randomized in some prepared way, so that a device dropping entries doesn't matter if the odds are that the device will successfully run through all passwords entries, despite dropping the occasional entry.

Am I misunderstanding how the iPhone dropped some of the entries on "testing"?

Re: urgk

[Anonymous Coward]

You mean it was an unclear summary. The story itself lays it out: the hacker said there is a way to send a stream of passcode attempts via cable to the iPhone which would override the 10 attempt limit. He later had to admit is that the method he used did not always send the attempt correctly to the phone and it was ignored thus not hitting the limit. He thought he sent 20 attempts when reality it was 5 or 6.

Not quite - he send all attempts, but after the 5th the iPhone doesn't accept any entries for 1 minute but (at least when using an external keyboard or pretending to) the GUI still looks like you enter numbers.

but they don't count, so no unlock

[Anonymous Coward]

This is like saying I can pull the trigger on a gun and never run out of bullets because the doing in the magazine isn't there...so while both are true the intended outcome isn't possible...a bullet leaving through the barrel. Here, the phone will never unlock since the unlocking mechanism is disabled.

Re:but they don't count, so no unlock

[Anonymous Coward]

" Here, the phone will never unlock since the unlocking mechanism is disabled."

How do you figure that from the articles?

yes it did

[aepervius]

I had changed the pin and could not remember the order of the digits but could remember the digits, so I tried permutation of the numbers until it unlocked. I got it after 10 or so tried.

Tapping quickly = hacking

[Anonymous Coward]

Millennials are murdering journalism.

How Is That A But?

[Anonymous Coward]

A security researcher claimed he had figured out a way to bypass the passcode lock limit on an iPhone or iPad, ZDNet reported. But it turned out the passcodes he tested weren't always counted.

If a password is tested but not counted, that sure sounds to me like bypassing the limit.

Re:How Is That A But?

[Anonymous Coward]

The system wasn't checking them, dopey.

pocket/butt erasing

[Anonymous Coward]

I remember pulling my phone from my pocket to see that it was erasing due to too many password attempts. There went all of my vacation photos.

I do not want this feature. I would rather allow a presumed intruder to see my vacation photos than to throw them in the trash.

Re: pocket/butt erasing

[Anonymous Coward]

It isnâ(TM)t enabled by default. So apparently you didnâ(TM)t.

Option in settings...

[The New Guy 2.0]

I can type ten bad passwords into my iPhone and not have it wiped. It's an option in settings that when turned off causes the phone to freeze and not accept a new attempt for a progressively longer time.

So there you have it, not all iPhones wipe after ten bad attempts.

Re:Option in settings...

[Anonymous Coward]

The "wipe the phone" part was very likely a simplification of speech, and a reasonable one as that is the default setting.

It would be more accurate but longer to explain to say "trigger the failed unlock handler" followed by the different options that could end up triggering.

But overall the researchers method was still flawed and doesn't actually bypass that feature no matter what the end result is configured to do.

He found a way to send many PINs in succession over one attempt, but in reality it seems this doesn't actually work despite the phone claiming it did.
(To be fair, my email spam filters work similar, they do not respond at all to the attacker making it appear the email was delivered, despite the fact it was not. This is to throw off the bad guys, since if the spam was delivered there would be no need to even try working around the filters)

It seems in this case he was sending 30 PINs over a single unlock request, and the phone implied/lied that it tried all of them when it didn't.
So he thought that because 30 is greater than 10, he was bypassing the limitations.
Or the fact he could send 270 PINs with no failed-pin-trigger, when the 271's actually did trigger it.

Apple says the phone only attempts and counts the first of the 30 in that single request.
If that's true it does add up.
30 pins per batch times 9 batches would imply 270 PIN checks, but as it only attempted the first one in the batch it was really only 9 PINs tried, which is certainly under the limit of 10.
The very next try, batched or not, would be 9+1=10, not 270+1 as the researcher thought.

Also if what Apple says is true, since it only tried 9 out of the 270 pins, there are 261 pins ignored. Thus if the correct pin is in there somewhere but in the 261 group, that pin wouldn't unlock the device and be shown as valid.

So hopefully what Apple says is correct. The researcher apparently responded, checked, and found it to be true, so that's at least promising.

Re:Option in settings...

[thegarbz]

Cool story. Not even remotely related to what is being done here, but cool none the less.

Not just 4-6 digits; Passphrase if you want

[Anonymous Coward]

This is a badly written article. Users don't just have a 4 or 6 digit pin as an option; I use a whole passphrase to unlock my iPhone (in the situation where touch ID isn't allowed - when touch-id failed too many times, it's been too long since it was unlocked, the device was powered off, or I did the five button press to disable it)

Can someone wipe my phone?

[Filter]

Does this mean that some jackass can wipe my phone by grabbing it and entering the wrong password 10 times? That would be a nasty prank.

Re:Can someone wipe my phone?

[Anonymous Coward]

If you enable that setting, yes. It is assumed that people who care enough about the data on their phones to want it to be wiped if someone else tries to access it would know better than to leave their phone unattended in the presence of pranksters.

Re:Can someone wipe my phone?

[PPH]

It is assumed that people who care enough about the data

... probably back it up someplace. And that backup should be accessible without the phone being connected (think broken phone, etc.) So you recover your phone, smack your jackass friend a couple of times, connect to the backup and pull your data back.

Re:Can someone wipe my phone?

[apoc.famine]

Some jackass can also grab your phone and toss it in the toilet, or smash it. How is this different?

If someone has physical access to your device, yes, they can destroy the data on it. In many different and exciting ways.

Re:Can someone wipe my phone?

[Anonymous Coward]

Did you bother to read the details? Like the part where you have to turn this feature on first?

It's intended for people to whom the privacy of their data is really important. If you don't turn the feature on, then the prankster can't cause the wipe by entering bad codes. They can hide your phone, or drunkenly drop it off a balcony, but they can't cause it to be wiped by entering bad codes.

You have backed up your phone, anyway, haven't you?

Apple better fix it

[omfglearntoplay]

From the comments and stuff I'm reading, Apple needs to step up and fix their junk.

Re:Apple better fix it

[Anonymous Coward]

Not until there are at least 3 class actions lawsuits.

Well gee this argument can be settled in 5 minutes

[Anonymous Coward]

Give him an iphone with a random PIN set, ask him to unlock it.

Duh.

Isn't this how GreyKey works?

[Anonymous Coward]

Presumably so. A strong passcode should still be hack-resistant.

A non-story

[Provocateur]

Maybe it is a non-story, then; the voice of a man crying out in the wilderne--wait, he's got cable.