Хватит винить пользователей в фишинге: проблема в архитектуре аутентификации
Почему совет «не кликай на подозрительные ссылки» — это полумера
Каждый год программы обучения безопасности внушают пользователям одно и то же: проверяй адрес сайта, ищи HTTPS, никогда не вводи пароль на незнакомых страницах. Теоретически — дельный совет. Но на практике мы построили системы аутентификации настолько запутанные, что фактически просим пользователей разгадывать головоломку, где правильный ответ меняется каждый квартал.
Вот неприятная правда: фишинг — это далеко не всегда ошибка пользователя. Часто это провал архитектуры.
Когда легитимные сайты выглядят как мошеннические
Задумайтесь на секунду — как выглядит ваш процесс авторизации? Если вы типичная компания, кнопка входа probably редиректит пользователей через лабиринт сторонних identity-провайдеров, федеративных сервисов аутентификации и токенизированных эндпоинтов, которые подозрительно напоминают фишинговые страницы.
https://app.yourcompany.com →
https://auth.identityprovider.io/yourcompany →
https://sso.federatedservice.com/session/token →
https://verify.authentication-processor.com/mfa
Ни один из этих адресов не принадлежит вашей компании. Ни один не запоминается. Ни один не даёт пользователю шанса отличить настоящее от подделки.
Атакующему нужно всего три вещи, чтобы воспроизвести этот опыт: убедительный шаблон, украденный логотип и поле для ввода пароля. Сам URL давно стал бессмысленным, потому что мы научили пользователей его игнорировать.
Почему URL никогда не проектировались для этой задачи
Будем честны — структура URL по своей природе сложна, и ждать от нетехнических пользователей умения разбирать её как разработчики просто нереально.
Возьмём для примера такой адрес:
https://login.staging.internal.example-corp.com/auth/verify
Большинство пользователей видят «staging» и «internal» — и их глаза стекленеют. Они ищут название компании, и даже когда находят, не могут понять — легитимная ли это инфраструктура или умелая имитация.
Хостнейм читается от частного к общему (login → staging → internal → example-corp → com), а это значит, что самый важный идентификатор — реальный домен — закопан где-то в середине. Пользователи привыкают искать название бренда в любом месте URL — и это именно та привычка, которую эксплуатируют фишеры.
Протокол → Субдомен(ы) → Домен → TLD → Путь
| | | | |
HTTPS login example com /auth
Разработчики понимают это интуитивно. Обычные пользователи не имеют никаких шансов, когда мы нормализуем такие URL:
https://auth.company.suspicious-vendor.io
https://company.auth-vendor.io/sso/abc123
https://auth-vendor.io/company-signin
Ответственность разработчика
Вот где начинается ваша зона влияния: вы можете проектировать аутентификацию так, чтобы она защищала пользователей по умолчанию.
Вместо редиректов через лабиринт сторонних доменов, придерживайтесь этих принципов:
1. Владейте своим identity-доменом. Аутентификация должна проходить на основном домене бренда. Если без стороннего identity-провайдера не обойтись — хотя бы используйте кастомный субдомен:
✓ https://login.yourcompany.com
✗ https://auth.vendor.com/yourcompany
2. Единая иерархия субдоменов.
Если основное приложение на app.company.com, авторизация должна быть на auth.company.com — а не закопана на три уровня в чужой инфраструктуре.
3. Умные редиректы. Когда нужно сослаться на внешние сервисы (опросы, платёжки, портал поддержки) — используйте серверные редиректы через свой домен. Это даёт пользователям консистентный опыт и закрепляет правило: «если не с нашего домена — значит, не наше».
4. Относитесь к SMS и телефонам так же. Сообщения «позвоните по этому номеру» или «отправьте код сюда» — не менее опасны, чем ссылки в письмах. Всегда указывайте контакты на странице, которой пользователи уже доверяют.
Безопасность, которая работает вместе с пользователем, а не против него
Терминология RFC 2119 — это не бюрократический жаргон, это философия проектирования. Когда безопасность аутентификации — это «SHOULD» вместо «MUST», мы получаем то, что имеем: дикий запад федеративных identity-сервисов, где легитимные сайты неотличимы от мошеннических.
Компании, которые выиграют в вопросах безопасности — это те, кто перестанет считать пользователей слабым звеном и начнёт строить системы, где безопасный выбор становится простым выбором.
Потому что реальность такова: нельзя «натренировать» пользователей выйти из проблемы, которую создал дизайн.
Что это значит для вашего стартапа или бизнеса
Если вы строите или поддерживаете процессы аутентификации — сейчас самое время для аудита. Задайте себе:
- Может ли новый пользователь определить вашу страницу входа по одному URL?
- Ведут ли все авторизованные процессы через домены, которые пользователи узнают?
- Используете ли вы BYO domain функции от сторонних сервисов или принимаете их дефолтные адреса?
Это не про security theater — это про построение доверия. Пользователи, которые уверены в вашем процессе авторизации, доверяют вашему продукту.
В NameOcean мы видим, как domain-стратегия пересекается с security-архитектурой. Ваш домен — это не просто адрес. Это фундамент доверия пользователей. Убедитесь, что он работает на вас, а не против.