i'm not sure how this security protect citizens from governments that don't provide them the same protections as the U.S. In many of those countries they can just torture you to get your pass code. No fancy equipment required.
This is a lesson learned for me. The original article headline read:
Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks
If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple.
This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility.
so much for the folks on the other thread that decried, “Apple is getting lazy! Sloppy design!” etc.
You are technically correct. But those of us who deemed that Apple had flubbed did not realize the article in question was not to be believed. AI technically should have verified the veracity of the story but I doubt they have the staffing, resources, or discipline to do so and risk missing the news cycle.
This is a lesson learned for me. The original article headline read:
Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks
If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple.
This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility.
Who do we believe?
Yes, AI evidently fell into the worst trap imaginable for a new service. I re-read the article, and never once does AI use the words: allegedly, may, might, could, appears, etc. To state the story as fact, and the claims as incontrovertible, without anything more than the guys word, and video demonstration. A simple “weasel” word would have saved them. That’s the definition of fake news. Mistakes do happen in reporting, but a news site should be limited to typos, or sources who conspire to manipulate them. A story like this should not rely on a sole claim as fact, without qualifying it, thus validating the source claim without review. MacRumors made the same mistake, so AI is in the same company.
This is a lesson learned for me. The original article headline read:
Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks
If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple.
This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility.
Who do we believe?
Yes, AI evidently fell into the worst trap imaginable for a new service. I re-read the article, and never once does AI use the words: allegedly, may, might, could, appears, etc. To state the story as fact, and the claims as incontrovertible, without anything more than the guys word, and video demonstration. A simple “weasel” word would have saved them. That’s the definition of fake news. Mistakes do happen in reporting, but a news site should be limited to typos, or sources who conspire to manipulate them. A story like this should not rely on a sole claim as fact, without qualifying it, thus validating the source claim without review. MacRumors made the same mistake, so AI is in the same company.
Too harsh. It’s a gray area. AppleInsider plays an important role in helping Apple enthusiasts stay connected with all things Apple. They are doing their best to keep the information flowing and whetting our insatiable appetite for inside information about our favorite company. They are not a vetting authority for information obtained from other sources and passed along for our consumption.
Sure, for articles, topics, and stories that do originate within AI they should be held to a higher standard by AI staffers. AI could add caveats to all non-AI sourced content but doing so would quickly fade into background noise by constantly repeating the same set of stock disclaimers. The learning aspect for me was the realization that information passed along from other sources through AI has to be vetted at the source/originator, not the intermediate messenger, despite the article headline.
The potential failure in this case occurred at the source with the security researcher who made a claim against Apple with insufficient verification and validation of his discovery/hypothesis.
Will a developer or security professional explain how you can send text through a lightning connector? I know data can be written and read through this port because iTunes does it when backing up an iPhone. What does it take for a peripheral to take over a locked iPhone? Typically, iTunes requires the unlock code to be entered before backing up. Just trying to get a technical understanding on the plausibility of this attempted hack. Be specific and show examples so all of us are more educated. Thanks
This is a lesson learned for me. The original article headline read:
Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks
If the above article proves to be wrong then all of the sites that presented the original story as fact and without “claims” or some other similar caveat terminology have done a great disservice to their readership and Apple.
This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility.
Who do we believe?
Well, first of all, you need to remember that AI isn't a news site; it's a news aggregator site. They basically pull stories from other sources and stick them here. So do not take anything they say at face value without checking the original source first. As we have seen in the past, they do interpret what they have read incorrectly through misunderstanding the technicalities of what they've read, or their own particular bias.
Who do we believe? Well I tend to veer towards sites with more technical chops, such as ArsTechnica, but even they get it wrong. In this case, I simply waited to hear what Apple had to say before commenting.
Yes, the headline turned out to be incorrect because the researcher didn't have his work reviewed, but AI did point out that the hack opened a door to brute force attacks; they did not say that this method in itself compromised the phone. So the first part of the headline was wrong, the second part was correct.
Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not? Which is it?
in regards to the notion that he found a bug etc, there was no suggestion. they flat out said he was lying. they just said it very politely.
They didn't say he was lying; they said he got it wrong.
When you say something you know not to be true, then that's lying.
He said something he believed to be true: he made a mistake. An amateurish mistake, but a mistake nonetheless.
Apple will not falsely accuse him of lying because, quite rightly, they do not want to be in a situation where hackers are afraid of submitting vulnerability reports in case they're lambasted by the company and its followers if/when they get it wrong. In this situation, Apple's response was measured and correct.
Anyway, the bloke corrected his original findings as soon as Apple contacted him.
No he wasn’t lying. He was just trashing his credibility. Let this be a lesson to you all, folks. If conducting experiments, make sure you test your results and conclusions, including by a critical peer, not your mates at the next university. And don’t ever rush to the social media sewer with untested results and conclusions.
The best thing is to test you are actually testing what you think you are testing.
Getting result X means nothing if you don't even know what you actually tested.
For example,
If you give poison to a test subject, make sure they actually swallowed it before declaring it can't kill the subject (in this case it is "kill it" :-), but the principle is the same).
And of course, this.
Now that sites are so obsessed with chasing page views, time taken for proper verification has gone out the window. I hope this trend isn't spreading to scientific research.
The tech press should have realised on day one that this woman was selling snake oil.
Why didn't they? Simple. She used the terms 'disruption' and 'iPod of healthcare' in her brochure and wore black turtlenecks to interviews. That's all it took.
parts list IBM PC AT or compatible w/ 16550 Uarts a copy of procomm plus 2.42 Serial To HID Keyboard Converter Cable ($99 - HIDMDB9USBA-3E ) usb gender changer ( F to F ) usb to lightning cable
you don't want to use a modern desktop pc , because you want to be retro going off the usb port probably be like software emulation of a serial port etc , you want to be as pure as possible
wikipedia says that a ps/2 keyboard operates between 7 to 12kbps , so 9600 should be okay
the 16550 uart is mandatory , if you use an older computer with a 8 bit uart, you might have problems sending/ receiving at 9600 baud going over 9600 on an older uart might drop characters
9600 baud is the fastest that this particular cable will support. you might be able to find that is 128k bps or better yet parallel but i wouldnt know how off hand to send characters down the printer port
so what you do is when you load up procomm and whatever DOS you have, and you either upload an ascii file of 0000 to 9999 to the adapter using 9600 N 8 1 to the iPhone with 4 digit pin numbers, and if this person's claim is true, then you should be able to replicate his claim. you could also use any number of terminate and stay resident programs or word processors to make your own keyboard macros as well.
i believe a keyboard macro would be faster then sending an ascii file.
something else to test
if this persons claim that a keystrokes cause the iPhone to stop doing all over tasks is true. then holding down a key on an external keyboard should also cause the iPhone to completely STOP what its doing. because thats how it was on the ibm clones.
back in the old days we had 8 interrupts max. when the pc at came out we had 16 , we now have 255 ??? i highly doubt the iPhone has a low number of interrupts.
regardless if you send it 10000 keystrokes all at once , or hold one key down for infinity, if the persons claim is true about interrupts , then the iPhone should come to a complete stop and not do any other tasks at all
Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not? Which is it?
My apologies. I didn't actually answer your second question.
In a word, no.
No article I've read (including the one here), has said that he actually broken into the phone. What he has done is demonstrate that the iOS's data erasure function can be bypassed, which could, in theory, lead to the development of an exploit that could be used to break into the phone. If you can stop the phone from erasing itself then you have more chances to break into it.
Unfortunately, this may not be the case because the reason the experimental phone did not erase itself is because it had not, as he first believed, received the ten password tries that triggers the function.
Thank you. That actually does answer my question. I'm still seeing 'newly published' headlines on this subject that make it sound like, indeed, the iPhone "has been hacked" with this method. ...infuriating.
No, even if his method was correct, he had not managed to weaponise the exploit to break into the phone. So what thought he found was a vulnerability: a possible attack vector.
That is what the vast majority of these exploits turn out to be.
Kind of confusing. Is Apple suggesting that the guy is lying? Or was he, in fact, able to break into the phone; or not? Which is it?
From the article, my reading comprehension has that the guy isn't lying, just that the result "was in error, and a result of incorrect testing" according to Apple.
The fact that the initial findings havn't been able to be replicated or validated by a third party indicates that Apple appears to be correct.
Then I just don't understand whet the "result" was. I had thought the "result" was that this guy had, indeed, brute-forced his way into an iPhone with this method (?)
The 'result' he thought he had was that on the 11th password attempt the phone did not erase itself. What actually happened was that he only sent four passwords.
He never said that on the 11th attempt he gained access to the phone. If that had happened then he would've hacked the phone.
Now that they know what he was trying to do, my guess is that Apple ran the same experiment again, but actually made sure that eleven passwords are tested by the security algorithm.
But!
One should bear in mind that this is a good reason why a four number passcode is something that should be avoided.
I'd also like to highlight @Soli's idea about allowing emojis to be used as password characters. I've noticed a few people online have tried this on MacOS and managed to lock themselves out of their system. I think Apple should support the use of emojis as password characters.
If this ever does come to pass, then please don't use any length variation of
💩💩💩💩
as a password, because that is the emoji equivalent of using 'passw0rd' as your password. It's the first thing a hacking algorithm will try out.
Another good reason for allowing emoji passwords: it'll stop banks doing insecure checks like asking for the second and fourth character of your code:
"Yes, it's a long distance runner followed by a pile of sh*t."
How would that work? Does an emoji appear to the OS as just a string of numbers, or is it something else? Seems like a great idea as long as emojis themselves don't have (or open up) some sort of unexpected vulnerability.
Another good reason for allowing emoji passwords: it'll stop banks doing insecure checks like asking for the second and fourth character of your code:
"Yes, it's a long distance runner followed by a pile of sh*t."
How would that work? Does an emoji appear to the OS as just a string of numbers, or is it something else? Seems like a great idea as long as emojis themselves don't have (or open up) some sort of unexpected vulnerability.
They are Unicode characters just like all the other characters we use today. For Apple to implement this in their OSes would be a cakewalk, but there are potenial pitfalls.
One universal issue is that some characters look very similar. Sure, the same can be applied to letters, numbers, and punctuation, but the detail of certain faces in pictograms, for example, could lead to confusion. The solution is to exclude any that are too close in appearance.*
The other issue is more of when this moves to websites, which means being cross platform. These pictpgrams are designed indeprently by the OS and device vendors. While the hamburger emoji may not be confusing despite looking radically different across platforms, others might. Specifically certain faces.
What if you only used Windows and Android and had the gun emoji in your passcode? Could anyone reasonably jump onto an Apple device and realize they need to use the toy gun? I think that’s well known on Apple forums, and you could probably search by name to find what you're looking for, but that may have to be excluded if it’s not deemed universal enough in appearance and having to search for a character does reduce efficiency.
The bottom line is that additional characters adds to the complexity of the passcode so even a few dozen emoji—not all 800-ish—is a huge boon for security.
* Right now in iOS and macOS you can create a passcode with a hyphen (-), en dash (–), or em dash (—). Visually they are close in appearance if you aren't looking at them side-by-side. Not a huge deal for an OS passcode, but if you were to make that an option for a website that could be a problem if you have to read it back, especially how different fonts can affect how these look. Because of that, I'd also remove all but the hyphen when it came to the passcode and make the use of the other two default to the hyphen automatically. I think many emoji would fall into that category, like the "confused face" 😕 (Unicode: U+1F615) v "slightly frowning face" 🙁 (Unicode: U+1F641) to name but two of many, many possibilities.
Jesus, I already told you how they do
it. The copy the encrypted ROM from the phone they are trying to hack
and flash it onto a new emulated chip. Try 10 pass codes and re flash the
chip and try another 10. As long as they only allow 6 digit pass codes ,
most codes will take a couple hours to 3 days max to crack.
Comments
Simple hack bypasses iOS passcode entry limit, opens door to brute force hacks
This is very unsettling to me and gives me pause about taking explosive headlines at face value. I originally felt that Apple had failed in their DfS approach but now I am more inclined to believe that the person making the assertion of such a serious security vulnerability without concrete proof is guilty of serious negligence and poor methodology and demonstrates a severe lack of credibility.
Who do we believe?
Sure, for articles, topics, and stories that do originate within AI they should be held to a higher standard by AI staffers. AI could add caveats to all non-AI sourced content but doing so would quickly fade into background noise by constantly repeating the same set of stock disclaimers. The learning aspect for me was the realization that information passed along from other sources through AI has to be vetted at the source/originator, not the intermediate messenger, despite the article headline.
The potential failure in this case occurred at the source with the security researcher who made a claim against Apple with insufficient verification and validation of his discovery/hypothesis.
Well, first of all, you need to remember that AI isn't a news site; it's a news aggregator site. They basically pull stories from other sources and stick them here. So do not take anything they say at face value without checking the original source first. As we have seen in the past, they do interpret what they have read incorrectly through misunderstanding the technicalities of what they've read, or their own particular bias.
Who do we believe? Well I tend to veer towards sites with more technical chops, such as ArsTechnica, but even they get it wrong. In this case, I simply waited to hear what Apple had to say before commenting.
Yes, the headline turned out to be incorrect because the researcher didn't have his work reviewed, but AI did point out that the hack opened a door to brute force attacks; they did not say that this method in itself compromised the phone. So the first part of the headline was wrong, the second part was correct.
They didn't say he was lying; they said he got it wrong.
When you say something you know not to be true, then that's lying.
He said something he believed to be true: he made a mistake. An amateurish mistake, but a mistake nonetheless.
Apple will not falsely accuse him of lying because, quite rightly, they do not want to be in a situation where hackers are afraid of submitting vulnerability reports in case they're lambasted by the company and its followers if/when they get it wrong. In this situation, Apple's response was measured and correct.
Anyway, the bloke corrected his original findings as soon as Apple contacted him.
This.
And of course, this.
Now that sites are so obsessed with chasing page views, time taken for proper verification has gone out the window. I hope this trend isn't spreading to scientific research.
Look at Theranos.
https://www.theguardian.com/commentisfree/2018/jun/03/theranos-elizabeth-holmes-media-emperors-new-startup
The tech press should have realised on day one that this woman was selling snake oil.
Why didn't they? Simple. She used the terms 'disruption' and 'iPod of healthcare' in her brochure and wore black turtlenecks to interviews. That's all it took.
parts list
IBM PC AT or compatible w/ 16550 Uarts
a copy of procomm plus 2.42
Serial To HID Keyboard Converter Cable ($99 - HIDMDB9USBA-3E )
usb gender changer ( F to F )
usb to lightning cable
you don't want to use a modern desktop pc , because you want to be retro
going off the usb port probably be like software emulation of a serial port etc , you want to be as pure as possible
wikipedia says that a ps/2 keyboard operates between 7 to 12kbps , so 9600 should be okay
the 16550 uart is mandatory , if you use an older computer with a 8 bit uart, you might have problems sending/ receiving at 9600 baud
going over 9600 on an older uart might drop characters
9600 baud is the fastest that this particular cable will support. you might be able to find that is 128k bps or better yet parallel but i wouldnt know how off hand to send characters down the printer port
so what you do is when you load up procomm and whatever DOS you have, and you either upload an ascii file of 0000 to 9999 to the adapter using 9600 N 8 1 to the iPhone with 4 digit pin numbers, and if this person's claim is true, then you should be able to replicate his claim. you could also use any number of terminate and stay resident programs or word processors to make your own keyboard macros as well.
i believe a keyboard macro would be faster then sending an ascii file.
something else to test
if this persons claim that a keystrokes cause the iPhone to stop doing all over tasks is true. then holding down a key on an external keyboard should also cause the iPhone to completely STOP what its doing. because thats how it was on the ibm clones.
back in the old days we had 8 interrupts max. when the pc at came out we had 16 , we now have 255 ??? i highly doubt the iPhone has a low number of interrupts.
regardless if you send it 10000 keystrokes all at once , or hold one key down for infinity, if the persons claim is true about interrupts , then the iPhone should come to a complete stop and not do any other tasks at all
That is what the vast majority of these exploits turn out to be.
The 'result' he thought he had was that on the 11th password attempt the phone did not erase itself. What actually happened was that he only sent four passwords.
He never said that on the 11th attempt he gained access to the phone. If that had happened then he would've hacked the phone.
Now that they know what he was trying to do, my guess is that Apple ran the same experiment again, but actually made sure that eleven passwords are tested by the security algorithm.
But!
One should bear in mind that this is a good reason why a four number passcode is something that should be avoided.
I'd also like to highlight @Soli's idea about allowing emojis to be used as password characters. I've noticed a few people online have tried this on MacOS and managed to lock themselves out of their system. I think Apple should support the use of emojis as password characters.
If this ever does come to pass, then please don't use any length variation of
💩💩💩💩
as a password, because that is the emoji equivalent of using 'passw0rd' as your password. It's the first thing a hacking algorithm will try out.
"Yes, it's a long distance runner followed by a pile of sh*t."
(No points will be given for a Paula Radcliffe joke or comments about this guy: https://metro.co.uk/2018/05/17/neighbour-catches-jogger-that-keeps-leaving-dirty-surprises-outside-his-house-7554405/).
One universal issue is that some characters look very similar. Sure, the same can be applied to letters, numbers, and punctuation, but the detail of certain faces in pictograms, for example, could lead to confusion. The solution is to exclude any that are too close in appearance.*
The other issue is more of when this moves to websites, which means being cross platform. These pictpgrams are designed indeprently by the OS and device vendors. While the hamburger emoji may not be confusing despite looking radically different across platforms, others might. Specifically certain faces.
What if you only used Windows and Android and had the gun emoji in your passcode? Could anyone reasonably jump onto an Apple device and realize they need to use the toy gun? I think that’s well known on Apple forums, and you could probably search by name to find what you're looking for, but that may have to be excluded if it’s not deemed universal enough in appearance and having to search for a character does reduce efficiency.
The bottom line is that additional characters adds to the complexity of the passcode so even a few dozen emoji—not all 800-ish—is a huge boon for security.
* Right now in iOS and macOS you can create a passcode with a hyphen (-), en dash (–), or em dash (—). Visually they are close in appearance if you aren't looking at them side-by-side. Not a huge deal for an OS passcode, but if you were to make that an option for a website that could be a problem if you have to read it back, especially how different fonts can affect how these look. Because of that, I'd also remove all but the hyphen when it came to the passcode and make the use of the other two default to the hyphen automatically. I think many emoji would fall into that category, like the "confused face" 😕 (Unicode: U+1F615) v "slightly frowning face" 🙁 (Unicode: U+1F641) to name but two of many, many possibilities.