Hacker News Reader

Comment by technofiend | Hacker News Reader

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.

View on HN

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.

>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.

> 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).

>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.

You're mixing up two different concepts. E-mail address and mailbox. Multiple e-mail addresses can be used to deliver to the same mailbox. That's what "local intepretation" means. a.a@b is still a different address than aa@b.

And in the end is what happens with gmail. You have one mailbox and all versions of your mailbox with dots in between the characters as alias automatically.

x.y.z@gmail.com and xyz@gmail.com are two entirely different email addresses.

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.

> It's left open to interpretation from my reading of the relevant RFC.

For security, I would prefer the more stringent interpretation over those that are more forgiving.

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.

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

CAN and CAN'T in this kind of documentation should sometimes be interpreted as WILL and WON'T, or HAVE BEEN TRAINED NOT TO.

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.

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

>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.

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.

Correct! I forgot, there was a little nuance there. Thanks for posting that.

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.

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

Reply on news.ycombinator.com