4 ms·

There's still a hole in Apple's user ID mapping that doesn't recognize first.last@gmail.com and firstlast@gmail.com are the same person and the e-mails go to th

There's still a hole in Apple's user ID mapping that doesn't recognize first.last@gmail.com and firstlast@gmail.com are the same person and the e-mails go to the same place. 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.

joombaga 8y ago
I don't understand. Can you describe the hole? It seems preferable to treat foo@gmail.com, fo.o@gmail.com, and foo+bar@gmail.com as different addresses.
klodolph 8y ago
What does this have to do with first.last@gmail.com being the same as firstlast@gmail.com? IMO the correct thing to do is treat the local part of the email address to be opaque.
pathseeker 8y ago
That's not a hole. Those are different email addresses according to the email standard. 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.
- technofiend 8y ago
  >Those are different email addresses according to the email standard. 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.
  - hk__2 8y ago
    > It's left open to interpretation from my reading of the relevant RFC 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).
    - technofiend 8y ago
      >The locally interpreted string is either a quoted-string or a dot-atom 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.
      - 8y ago
xGrill 8y ago
Calling apple support and raising hell until someone makes a mistake is more social engineering than email address security vulnerability.
babblingdweeb 8y ago
I cannot speak for other email providers, but my understanding for the past 10 years: this is a Google thing vs. Apple. Google both allows and ignores periods in emails. first.last@gmail.com is the SAME email address as firstlast@gmail.com you CANNOT log in with both accounts. If you created your account as first.last@gmail.com, you can only log in by using that email address. For more information from Google on this topic: https://support.google.com/mail/answer/7436150?hl=en https://support.google.com/mail/answer/7436150?hl=en
- irrational 8y ago
  >If you created your account as first.last@gmail.com, you can only log in by using that email address. 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.
  - snowwrestler 8y ago
    Based on my own limited testing, it seems like you can remove dots but not add them during login. 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.
    - babblingdweeb 8y ago
      Correct! I forgot, there was a little nuance there. Thanks for posting that.
ryannielsen 8y ago
From Apple's own two-factor account support documentation: "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. https://support.apple.com/en-us/HT204921 https://support.apple.com/en-us/HT204921
- joombaga 8y ago
  CAN and CAN'T in this kind of documentation should sometimes be interpreted as WILL and WON'T, or HAVE BEEN TRAINED NOT TO.
  - duskwuff 8y ago
    A friend of mine used to work in Apple's account security phone department, and can confirm that they really do mean CAN'T. Support techs can view a few bits of information that aren't displayed to the user, but cannot change anything.

joombaga 8y ago

I don't understand. Can you describe the hole? It seems preferable to treat foo@gmail.com, fo.o@gmail.com, and foo+bar@gmail.com as different addresses.

klodolph 8y ago

What does this have to do with first.last@gmail.com being the same as firstlast@gmail.com? IMO the correct thing to do is treat the local part of the email address to be opaque.

pathseeker 8y ago

That's not a hole. Those are different email addresses according to the email standard. 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.

technofiend 8y ago
>Those are different email addresses according to the email standard. 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.
- hk__2 8y ago
  > It's left open to interpretation from my reading of the relevant RFC 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).
  - technofiend 8y ago
    >The locally interpreted string is either a quoted-string or a dot-atom 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.
    - 8y ago

xGrill 8y ago

Calling apple support and raising hell until someone makes a mistake is more social engineering than email address security vulnerability.

babblingdweeb 8y ago

I cannot speak for other email providers, but my understanding for the past 10 years: this is a Google thing vs. Apple. Google both allows and ignores periods in emails. first.last@gmail.com is the SAME email address as firstlast@gmail.com you CANNOT log in with both accounts. If you created your account as first.last@gmail.com, you can only log in by using that email address. For more information from Google on this topic: https://support.google.com/mail/answer/7436150?hl=en https://support.google.com/mail/answer/7436150?hl=en

irrational 8y ago
>If you created your account as first.last@gmail.com, you can only log in by using that email address. 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.
- snowwrestler 8y ago
  Based on my own limited testing, it seems like you can remove dots but not add them during login. 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.
  - babblingdweeb 8y ago
    Correct! I forgot, there was a little nuance there. Thanks for posting that.

ryannielsen 8y ago

From Apple's own two-factor account support documentation: "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. https://support.apple.com/en-us/HT204921 https://support.apple.com/en-us/HT204921

joombaga 8y ago
CAN and CAN'T in this kind of documentation should sometimes be interpreted as WILL and WON'T, or HAVE BEEN TRAINED NOT TO.
- duskwuff 8y ago
  A friend of mine used to work in Apple's account security phone department, and can confirm that they really do mean CAN'T. Support techs can view a few bits of information that aren't displayed to the user, but cannot change anything.