Gmail Address Variants Bypass String Comparison and Enable Multiple Registrations

A single user created four separate accounts using valid Gmail address formats that all deliver to the same inbox: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, and IVAN.PETROV@gmail.com. Simple string comparison in the registration code treated these as distinct entries, allowing circumvention of new-user promotions, free-tier limits, and one-application-per-person rules. The root cause lies in three Gmail-specific behaviors: case-insensitive local parts, plus-addressing that ignores everything after the + symbol, and dots that carry no semantic meaning in the local part. Additional risks arise from IDNA homograph domains that visually mimic legitimate addresses but encode to different Punycode strings. Proper mitigation requires storing both the original email for delivery and a domain-aware normalized form for uniqueness checks, combined with explicit IDNA validation on registration.

HabrTranslated from Russian

Read at source

A developer investigation revealed that one user had successfully registered four separate accounts using only legitimate Gmail address variants that all route to the same mailbox: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, and IVAN.PETROV@gmail.com.

Colleagues noticed more user records than actual people in the database. The discrepancy traced back to a single line of code that compared email addresses as raw strings without normalization.

Gmail treats the local part of an address case-insensitively, discards everything after a plus sign, and ignores dots. These rules let one inbox generate an unlimited number of distinct strings that still receive mail at the same destination.

Why string comparison fails

Three common cases break naive equality checks:

  • Case differences in the local part or domain
  • Plus-addressing suffixes such as +shop or +promo
  • Dots inserted anywhere in the local part of a Gmail address

Normalization must be applied selectively. Dots are ignored only for gmail.com and googlemail.com; applying the same rule to other providers would incorrectly merge unrelated mailboxes.

Homograph domain attacks

A separate but related threat appears when domains contain visually identical Cyrillic characters. The string еxample.ru (with Cyrillic е) encodes under IDNA to xn--xample-2of.ru, creating a look-alike address that passes superficial inspection yet points elsewhere.

Recommended implementation

Store two fields: the original address for sending mail and a normalized address for uniqueness enforcement. Perform lower-casing on the entire address, strip plus-suffixes only for Gmail, remove dots only for Gmail, and run every submitted domain through IDNA encoding to detect hidden non-ASCII labels. A simple confirmation email remains the most reliable validator of deliverability.

A diagnostic query can surface existing problems by grouping on the normalized domain and comparing raw versus deduplicated local parts.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild