Одна точка в Gmail — и для сервиса перед вами уже другой пользователь. Мы наткнулись на это случайно, а потом решили проверить, насколько далеко можно зайти.

Я работаю в молодой компании, которая занимается цифровыми сервисами. Сразу оговорюсь: я не разработчик, а отвечаю за контент и креативную часть. Вообще нюансы работы техотдела — кладезь интересных и полезных историй, но вытянуть из них все технические детали удается весьма нечасто. А тут в курилку заходит один из разработчиков и оживленно рассказывает, как они с коллегой в тот день фиксили какие‑то баги, проверяли данные пользователей и совершенно случайно заметили два практически одинаковых адреса Gmail с одним лишь отличием — положение точки. Условно: example.user@gmail.com и exam.pleuser@gmail.com

Решили проверить на собственном ящике — написали письмо на несколько вариантов адреса, просто переставляя точку. И все письма пришли в один и тот же ящик…

Не знаю, удивит ли вас то, что я была заинтригована, но мгновенно превратившись в почемучку, стала вытягивать подробности и пояснения. Почему это работает? Что именно в таком случае видит наша система? Можно ли таким образом создавать несколько аккаунтов и насколько вообще это серьёзная проблема?

Я решила записать этот кейс подробно. Во‑первых, хотелось бы понять, насколько часто разработчики учитывают подобное при регистрации пользователей, а во‑вторых, вдруг кому‑то из небольших команд и стартапов эта история будет интересна.

Подтверждённый email не означает уникального пользователя 

Мы привыкли считать подтверждение почты доказательством уникальности пользователя, на деле же переход по ссылке подтверждает лишь то, что человек имеет доступ к данному почтовому ящику. Он не подтверждает, что этот ящик ещё не использовался в системе, перед нами новый человек или что адрес не является другой записью того же ящика.

Разгоняя практические возможности этой особенности, наши ребята посчитали, сколько таких вариантов вообще можно получить (привожу дословно как фотку с маркерной доски).

Предположим, имя почтового ящика состоит из n символов. Между ними находится n − 1 промежутков. В каждом промежутке точку можно либо поставить, либо не поставить.

Получается: количество вариантов = 2^(n − 1)

Например, если имя содержит 15 символов: 2^14 = 16 384

То есть теоретически можно получить 16 384 разные строки, которые стороннее приложение способно принять за разные адреса, хотя Gmail будет доставлять сообщения в один ящик. На практике число может быть меньше из‑за ограничений конкретной формы регистрации, длины адреса и других проверок. Но даже нескольких вариантов достаточно, чтобы обойти логику, основанную на правиле «один email — один пользователь».

Причем Gmail работает именно так по задумке, это не ошибка. Владелец адреса без точек владеет и всеми его вариантами с точками. Другой человек не может отдельно зарегистрировать такой dotted‑вариант в Gmail. В официальной справке Google, собственно, так и указано.

Уязвимое место находится как раз на стороне сервиса, который использует email как уникальный идентификатор, сравнивает адреса как обычные строки, не учитывает особенности конкретного почтового провайдера, считает подтверждение адреса достаточной защитой от повторных регистраций. Как в нашем случае. На уровне приложения при регистрации наша система получала email, проверяла его формат, искала совпадение в базе и, если точной такой строки ещё не было, создавала нового пользователя.

Чем это может быть опасно для продукта

Выяснилось, что само по себе создание нескольких аккаунтов не всегда критично. Всё зависит от того, какие возможности сервис привязывает к пользователю. То есть когда правило «один пользователь — одна возможность» на уровне архитектуры реализовано как «одна строка email — одна возможность». Тогда разные варианты одного Gmail‑адреса в зависимости от логики конкретного сервиса могут позволить:

• повторно получать приветственные бонусы;

• участвовать в одной акции несколько раз;

• создавать дополнительные реферальные связи;

• обходить ограничения на количество операций;

• регистрироваться после блокировки одной учётной записи;

• разделять историю действий между разными профилями;

• искажать продуктовую аналитику и количество уникальных пользователей.

Можно ли просто убрать точки перед сохранением email?

Нет… Потому что правило с точками — это особенность Gmail, а не электронной почты вообще.

У другого почтового сервиса адреса, отличающиеся только положением точек, вполне могут принадлежать разным людям. Более того, даже у Google для корпоративных и учебных аккаунтов на собственных доменах точка может иметь значение. Поэтому логичнее не менять сам адрес, который ввёл пользователь, а хранить его отдельно и при необходимости формировать дополнительное значение для сравнения или антифрод‑проверки. И уже к нему применять правила конкретного почтового провайдера.

Можем ли мы сейчас дать универсальное решение проблемы?

Тоже нет. Ведь на практике один и тот же email используется сразу для нескольких разных задач.

1. Адрес для доставки

   Это значение, на которое нужно отправлять письма. Его желательно сохранить в том виде, в котором его указал пользователь.

   email_original

2. Идентификатор для сравнения

   Это форма, используемая для поиска уже существующей учётной записи. Здесь можно безопасно нормализовать доменную часть, но правила для имени ящика требуют осторожности.

   email_comparison_key

3. Сигнал для антифрода

   Даже если продукт допускает создание нескольких профилей, ему может потребоваться понять, что несколько адресов, вероятно, относятся к одному почтовому ящику.

   email_risk_key

В сильно упрощённом виде логика для антифрод-проверки могла бы выглядеть так:

function makeRiskKey(email):
    localPart, domain = parse(email)
    domain = lowercase(domain)

    if domain == "gmail.com":
        localPart = removeDots(localPart)

    return localPart + "@" + domain

Но это именно концептуальный пример, его нельзя автоматически применять ко всем доменам. Кроме того, совпадение такого ключа не обязательно должно приводить к слиянию аккаунтов. В одном продукте это будет причиной отклонить повторную регистрацию, в другом — поводом запросить дополнительную проверку, а в третьем — всего лишь одним из сигналов для оценки риска.

А ещё даже правильно обработать email во время регистрации недостаточно. Если правила сравнения отличаются в разных частях продукта, возникают новые странные сценарии. Например, регистрация считает два адреса одинаковыми, а восстановление пароля — разными. Или административная панель находит пользователя только по тому варианту адреса, который он ввёл изначально. Поэтому одинаковые правила стоит проверить как минимум в следующих местах:

• регистрация;

• авторизация;

• восстановление пароля;

• изменение email;

• привязка стороннего аккаунта;

• выдача бонусов и участие в акциях;

• реферальная система;

• поиск пользователей в админке;

• аналитика уникальных регистраций;

• ограничения частоты запросов.

Расскажите, как это решено у вас? Нормализуете Gmail-адреса, используете такие совпадения только как антифрод-сигнал или вообще не считаете мультиаккаунты проблемой?