The following provides some information on a security vulnerability in id.me, an identity solution that has broad adoption in the USA, including integration with the Social Security Administration and other local and national government agencies.
First, a brief primer on names and email addresses. RFC 5321 defines the Simple Mail Transport Protocol (SMTP) upon which email is based. Many enhancements and additions have been made around SMTP, most notably around spam protection. However the core aspects of an email address definition and how email is sent and received are unchanged. An email address is of the form recipient@domain, where recipient is a defined series of characters, and the domain is a registered domain. A server processing email on the domain decides on eventual delivery, and provision of a 'display name'. Let's have a few examples:
- "Michael Smith <mikesmith@gmail.com>" would refer to a display name of "Michael Smith" and a recipient of "mikesmith" on the domain gmail.com.
However, even though we know Mike is short for Michael, there's no requirement for the display name to match the recipient.
- "Michael Smith <immaterialscience@gmail.com>" would refer to a display name of "Michael Smith" and a recipient of "immaterialscience" on the domain gmail.com
OK, so that's fairly clear that there's no relationship, but what about this?
- "Albert Einstein <vonneumann@gmail.com>" would refer to a display name of "Albert Einstein" and a recipient of vonneumann on the domain gmail.com
Whilst this would be frowned upon from an etiquette perspective, there's nothing to prevent it from happening, because, again, there's no relationship.
Let's throw one more spanner in the works, with a specific particularity of Gmail. Dots (periods) do not matter in gmail addresses. That is, the following email addresses are the same (taken from the Google support article example) :
- "John Smith <john.smith@gmail.com>"
- "Jack Smith <jo.hn.sm.ith@gmail.com>"
- "Robert Jones <j.o.h.n.s.m.i.t.h@gmail.com>"
(Side note : this can be exceptionally problematic where punctuation changes meaning, such as for therapist@gmail.com).
With that set up, let's proceed to id.me.
The first issue is that id. me doesn't verify email address ownership. That is, an individual can use an email address not belonging to them to establish an id.me account, and id.me doesn't check. Contrast this to many well behaved services that will send an email to the address entered and require the user to click on a link or enter a code contained in the message, to confirm ownership. id.me doesn't do this.
Next we'll combine this issue with the Gmail 'dot' peculiarity, to get the following :
Individual A signs up for id.me using "Individual A <noperiod@gmail.com>" as the email address for registration.
Individual B who owns "Individual B <no.period@gmail.com>" receives emails for this user.
Individual B can successfully reset the account for A (via email) and fully access Individual A's account.
Two additional vulnerabilities in id.me's design come to light if Individual B is a good actor and contacts id.me to attempt to correct their errors. Id.me will not allow account deletion without upload of documents (such as a drivers license) to prove identity. So, individual B, who didn't create the account but has access to it, has no way to delete the account without uploading their PII. Finally, id.me relies on security through obscurity in that they won't disclose the 'authoritative sources' that they check the upload id against.