I'm surprised that nobody mentioned how big of a target this is for the criminal enterprise. Gaining unauthorized access to someone's account through this portal would be a gold mine, even better than iCloud alone.
"The release of iOS 11" ... "also made a number of other changes under the hood" ... "Each and every one of these changes was aimed at making the user’s life easier (as in “more convenience”), and each came with a small trade off in security. Combined together, these seemingly small changes made devastating synergy, effectively stripping each and every protection layer off the previously secure system."
"The passcode. This is all that’s left of iOS security in iOS 11. If the attacker has your iPhone and your passcode is compromised, you lose your data; your passwords to third-party online accounts; your Apple ID password (and obviously the second authentication factor is not a problem). Finally, you lose access to all other Apple devices that are registered with your Apple ID; they can be wiped or locked remotely. All that, and more, just because of one passcode and stripped-down security in iOS 11."
I don't know if it got any better with iOS 12.
I’d still like to see anything that disproves their claims and support yours which appear to be unsupported. Elcomsoft documents in details what changed in the whole system. And the post was already discussed on HN and I haven’t seen anybody disproving it:
Until iOS 11 what existed was
1) your "digital identity" by Apple (Apple ID and Apple ID password)
2) your "physical identity" (fingerprint) stored only at the device(s) and impossible to extract.
3) the "device key" that allowed the access to the device, but not to the (1)
And they were separated.
Since iOS 11, snooping the (3) and stealing the device is completely enough to overtake (1). Before iOS 11, that was simply not possible.
That's the whole point of the article I've quoted: if I just simply see which passcode you type and then I get an access to your device, you lose your Apple ID and everything it protects but that is not on your device.
It your Apple ID doesn't protect some additional material that is not on that single device, you don't have to care. If it does, it does make a difference. It's real.
And it's on topic. The post to which I've replied claimed:
"Someone would need my apple id, my password, access to one of my apple devices (I had to enter a code that appeared on one of my devices" ( https://news.ycombinator.com/item?id=18241224 )
Whereas in fact since iOS 11, somebody needs just access to one of his devices and the passcode, Apple ID and the password he can obtain having only the passcode and the device, since iOS 11.
The Elcomsoft's article explicitly claims that no, you don't need Apple Id and password when you have an access to the device and the passcode.
And nobody was able to disprove these very specific claims that are the actual topic of Elcomsoft's article.
What you assert, in the words you assert "the sum of changes would make this a weaker target", was claimed nowhere as the "argument". From the two paragraphs I've quoted the first was a mere introduction (how the reduced security level was achieved, specifically, "Combined together, these seemingly small changes made devastating synergy", and yes, such changes can actually make the system easier to exploit, everybody wit experience in this field knows that). The second was explicit:
"The passcode. This is all that’s left of iOS security in iOS 11. If the attacker has your iPhone and your passcode is compromised, you lose your data"
It was just your interpretation, based only on one of the only two paragraphs I've quoted (and your unawareness of both the second paragraph and the whole article) which obviously missed the whole point. Yes, the user "convenience" decisions did lead to having the Apple Id password irrelevant (obtainable by just a plain and typically simpler passcode). Sorry that you missed that. Any I won't reply to this thread anymore, because I've written all the arguments. Anybody can check the whole thread and compare.
And yes, also read the Elcomsoft's article and prove them wrong, if they are wrong. But I haven't seen anybody achieving that up to now.
None of the iOS related things apply to the download portal, and none of the intercept/local access exploits apply to normal users.
It is absolutely relevant for this very thread: it disproves the initial claim in the thread that the attacker would need “device, passcode and appleid password”. The article proves that the third (appleid password) is not needed (that was the main topic of the article) and you never demontrated anything else.
I don’t care for other kinds of relevance or irrelevance as they never were never claimed by me.
If you want to scope the thread to the Elcomsoft article and specific on-device physical extraction, sure you'd have a different story.
"Someone would need my apple id, my password, access to one of my apple devices (I had to enter a code that appeared on one of my devices), and access to my email." Note: "someone would need my" -- as in "an attacker", not "me as the owner of the device."
And the answer, supported by the Elcomsoft's article is, no, the attacker just needs the device and the passcode. Nothing more. Since iOS 11, everything else he can extract from that.
If you accidentally approve creating an Apple ID that's some variation on your e-mail it opens up your account to human phishing attacks. Just call apple support and raise hell until someone makes a mistake.
The RFC mentions dot-atoms in address elements are locally interpreted. There's no rule specifying if x.y.z or xyz are equivalent or not. The issue for me is that an Apple ID looks just like an e-mail address. x.y.z@gmail.com and xyz@gmail.com are equivalent to Gmail but not to Apple. From that I believe it creates an opportunity for confusion.
How exactly would this attack even work that you have in mind? And wouldn't it even be easier to conduct this so-called attach on an email host that actually treats first.last@domain.com as a different email from firstlast@domain.com since it wouldn't even require the 'victim' to click anything in their email?
The right answer is for Apple to keep treating them as separate emails and refuse to give people access to accounts with different email addresses. It's that simple.
Not really. It's left open to interpretation from my reading of the relevant RFC. The spec says the dot-atom form should be used but does not say in what way it should be used. Google collapses x.y.z@gmail and xyz@gmail.com to the same thing which is fine they're welcome to do so. However the Apple IDs x.y.z@gmail.com and xyz@gmail.com are entirely different entities. So we have a namespace collision in one space but not the other because although an Apple ID looks like an e-mail address it's not. I'm just saying that can create a problem.
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used. Comments and folding white space
SHOULD NOT be used around the "@" in the addr-spec.No. The part of the spec you quoted says that if the local part of the email address is in the format "atext+ (\. atext+)*" where atext is "Any character except controls, [spaces], and specials", then the quoted-string form shouldn’t be used. In other words, don’t use quotes when you don’t need them. This has nothing to do with how to "interpret" dots; they are interpreted like any other char except they can’t occur everywhere in the local part (e.g. "foo.@bar.com" isn’t valid).
That's pretty clearly stating (to me) that the dot-atom is locally interpreted. It doesn't say anything about how to interpret a dot-atom. Just to use it in preference to the quoted string if the rules you mention apply.
It just so happens that Google decides to treat them as the same for incoming mail.
Apple is under no obligation to treat them as the same. Neither is any other web service.
If you expect the web services you use to treat them as the same, then I foresee major disappointment in your future.
For security, I would prefer the more stringent interpretation over those that are more forgiving.
For more information from Google on this topic: https://support.google.com/mail/answer/7436150?hl=en
I don't think that's quite right if I'm understanding what you are saying. I've logged into my gmail account using both my.email.address@gmail.com and myemailaddress@gmail.com. Both work and both take me to the same account.
So if you created your account as my.name@gmail.com, you can also log into Google with username myname@gmail.com.
But if you created your account as myname@gmail.com, you can't log in with my.name@gmail.com.
"While [Apple Support] can answer your questions about the account recovery process, we can't verify your identity or expedite the process in any way."
Even if you manage to confuse a support agent, they cannot do anything to speed account recovery or be socially engineered into account compromise.
2FA popping up on your personal device that you authorized, even when that's the same device you're trying to log in on, doesn't reduce the security of that.
Exchanging her phone for a new one meant we could not activate her new phone without creating a new account.
Reminds me of how when I sign into my Gmail from another computer, it sends me an email saying "alert! someone signed in from this computer!" which I could immediately delete if I was a hacker. Seems useless to me.
Closest thing is UPS mailing me a PIN to authenticate the address for the My Choice portal.