Сброс пароля и восстановление доступа без дыр: полный технический разбор

Механизм, который ломают чаще всего — и делают это незаметно

Почему сброс пароля — это точка входа номер один

Принято думать, что главный вектор атаки на аккаунт — это брутфорс или фишинг. Но злоумышленники давно заметили более простой маршрут: форма "Забыли пароль?" чаще всего реализована небрежно, проверяется реже и находится за пределами основного threat model команды.

Статистика говорит сама за себя. В 2024 году число ATO-атак (account takeover) выросло на 24% год к году [8]. По данным SpyCloud, у пользователей, попавших в два и более брича, 70% паролей используются повторно [9]. В совокупности это создаёт идеальные условия для атак на recovery-флоу: атакующий уже знает email жертвы из утечки — ему нужно только захватить процедуру сброса.

Не менее показательна статистика по самому механизму атаки: по данным LexisNexis Risk Solutions, атаки через сброс пароля выросли в четыре раза за последний год, и каждый четвёртый запрос на reset является мошенническим [1]. При этом, по данным Forrester, каждый легитимный сброс пароля обходится компании примерно в $70 с учётом нагрузки на helpdesk и поддержку [10].

Важная деталь: для атакующего сброс пароля привлекателен ещё и тем, что после него он получает легитимные учётные данные. Никакого вредоносного ПО, никаких эксплойтов — просто корректный логин [10].

Анатомия уязвимого recovery-флоу

Рассмотрим типичные уязвимости по классам — от наиболее критичных к менее заметным, но стабильно работающим на практике.

1. Host header injection и password reset poisoning

Это одна из наиболее недооценённых уязвимостей. Когда приложение генерирует ссылку для сброса пароля, оно должно знать свой собственный домен. Если для этого используется значение HTTP-заголовка Host из запроса — без проверки — атакующий может подменить его на домен под своим контролем.

Сценарий атаки описан в документации PortSwigger Web Security Academy [11]:

1. Атакующий отправляет запрос на сброс пароля жертвы с модифицированным заголовком Host: attacker.com.
2. Приложение генерирует ссылку вида https://attacker.com/reset?token=... и отправляет её на email жертвы.
3. Жертва кликает по ссылке из письма — токен уходит на сервер атакующего.
4. Атакующий использует токен для сброса пароля и захвата аккаунта.

Примечательно, что это не экзотика: публичная база GitHub Advisory Database содержит многочисленные CVE именно по этому вектору. В 2024 году уязвимость была зафиксирована в Pimcore (CVE-2024-23648) [12] и в NPM-пакете @perfood/couch-auth [13], в начале 2025 года — в Kanboard [14].

Корень проблемы в том, что разработчик не задаётся вопросом: "А откуда берётся hostname в ссылке для сброса?" — и не проверяет, совпадает ли он с настроенным в конфигурации приложения. Согласно OWASP Testing Guide, если application_url или аналогичная переменная не задана явно, фреймворк подставляет значение из заголовка запроса — и это становится уязвимостью по умолчанию [15].

Защита: всегда генерировать reset-ссылки на основе статически заданного базового URL из конфигурации, никогда не доверять заголовку Host при построении ссылок в email.

2. Утечка токена через Referer-заголовок

Если reset-токен передаётся в URL (что само по себе уже субоптимально), и страница подтверждения подгружает сторонние ресурсы — аналитику, рекламу, скрипты виджетов — токен автоматически утекает в заголовке Referer при каждом запросе к этим ресурсам [15].

Это более тонкая уязвимость, её часто не замечают при code review: разработчик добавил GA4 или Hotjar на страницу подтверждения, не подумав о том, что URL этой страницы содержит чувствительный параметр.

Защита: заголовок Referrer-Policy: no-referrer или strict-origin на странице сброса; предпочтительнее — передавать токен через POST-тело, а не через URL.

3. Timing-атаки и перечисление пользователей (user enumeration)

Если приложение отвечает на запрос сброса пароля по несуществующему email медленнее, чем по существующему (или наоборот), атакующий может построить карту реальных пользователей системы. Разница в 500 мс между ответами уже достаточна для надёжной классификации [16].

Реальные случаи: Django (CVE-2024-39329, исправлен в 4.2.x, 5.0.x, 5.1.x) — стандартизирование времени выполнения verify_password() [17]; Mautic (CVE-2024-47057) — разница во времени ответа на форме "Забыли пароль?" позволяла перечислять пользователей [18]; Directus (CVE-2026-26185) — 500 мс разницы при невалидном reset_url [16]; Silverstripe Framework (GHSA-7m2v-x7rg-5hm5) — timing-атака на формах логина и сброса [19].

OWASP Forgot Password Cheat Sheet прямо предписывает: ответ на запрос сброса должен занимать одинаковое время вне зависимости от того, существует аккаунт или нет — через асинхронную обработку или искусственное выравнивание времени [2].

Отдельная проблема — различные текстовые ответы. Сообщение "Email не зарегистрирован" прямо сообщает атакующему, что такого аккаунта нет. Корректная реализация: одинаковое сообщение для обоих случаев — "Если такой email зарегистрирован, вы получите письмо".

4. Небезопасные токены: предсказуемость и хранение

Токен сброса пароля должен обладать несколькими свойствами одновременно: быть криптографически случайным, достаточно длинным для защиты от брутфорса, одноразовым, привязанным к конкретному пользователю в базе данных, иметь ограниченный TTL и храниться в хешированном виде [2].

По требованиям OWASP, токен должен:

1. Генерироваться через CSPRNG (cryptographically secure random number generator).
2. Иметь TTL 15–60 минут (для особо чувствительных систем — короче).
3. Быть инвалидирован немедленно после использования.
4. Храниться в базе в хешированном виде (SHA-256 или аналог) — не в открытом тексте [20].

Пункт про хранение хеша особенно важен: если атакующий получит дамп таблицы токенов, хранящихся в открытом виде, он может применить их ко всем ожидающим подтверждения аккаунтам. Хеш устраняет этот риск.

NIST SP 800-63B-4, финализированный в июле 2025 года, прямо ужесточил требования: обязательная проверка паролей по базам скомпрометированных учётных данных стала "SHALL" (обязательно), а не "SHOULD" (рекомендуется) [3].

5. Отсутствие инвалидации сессий после сброса

Это систематически встречающаяся ошибка: пользователь сбросил пароль, но все активные сессии остались в силе. Сценарий атаки очевиден: атакующий похитил сессионный cookie (через XSS, MITM или другую технику), жертва заметила это и сменила пароль — но сессия атакующего по-прежнему активна [21].

Из публичных отчётов платформ bug bounty видно, что эта уязвимость встречается регулярно: она зафиксирована на HackerOne (отчёт #224362, #678050), на Bugcrowd, в GitHub Advisory Database (GHSA-99hm-86h7-gr3g для ZenML 0.56.3) [22]. Паттерн один и тот же: смена пароля в одном браузере не прекращает сессию в другом.

Согласно OWASP, после сброса пароля следует либо автоматически инвалидировать все сессии, либо явно предложить пользователю это сделать [2]. OWASP A07:2025 (Authentication Failures) дополнительно указывает: сессионные идентификаторы должны инвалидироваться при выходе и после таймаутов [23].

CVE-2023-7028: когда одна строчка кода роняет всё

GitLab — показательный кейс того, насколько чувствительна логика сброса пароля к точечным изменениям.

В мае 2023 года в GitLab 16.1.0 был добавлен новый функционал: возможность отправить письмо для сброса пароля на резервный email-адрес. Разработчик сделал одну ошибку: отправка письма на этот адрес не требовала его предварительной верификации [5].

Последствия: атакующий без какого-либо взаимодействия с жертвой мог указать свой email как получателя ссылки для сброса, получить токен и захватить аккаунт. CVSS score — 10.0 (максимум). CISA добавила уязвимость в каталог Known Exploited Vulnerabilities [5].

По данным Shadowserver Foundation, спустя две недели после публикации патча в январе 2024 года более 5000 GitLab-серверов оставались неустановленными, включая сотни в России и Германии [24]. PoC-скрипт появился в публичном доступе одновременно с исправлением.

Единственное, что спасало аккаунты с включённым 2FA, — даже получив токен для сброса пароля, атакующий не мог войти без второго фактора [25].

Вывод из этого кейса: проверка email перед любой привилегированной операцией — не формальность, а архитектурный принцип. Логика "добавим удобство, а верификацию доделаем потом" создаёт дыры с максимальным CVSS.

Helpdesk как вектор атаки: социальная инженерия обходит MFA

Технически корректный сброс пароля не защищает от человеческого фактора в цепочке. Именно поэтому helpdesk-процедуры восстановления доступа стали отдельным вектором атаки.

Группа Scattered Spider (она же UNC3944) специализируется на именно этом подходе: злоумышленники звонят в службу поддержки, представляются сотрудниками, убеждают сбросить пароль или перепривязать MFA — и получают легитимный доступ без единой технической уязвимости. ФБР и Mandiant зафиксировали эту тактику как часть операций группы в 2024–2025 годах [6].

Взлом MGM Resorts в 2023 году по той же схеме обошёлся компании в более чем $100 миллионов и привёл к полной остановке IT-систем на несколько дней. Атакующим хватило одного звонка в helpdesk.

Проблема в том, что процедура верификации личности при сбросе пароля через helpdesk часто слабее, чем сама процедура аутентификации. Аутентификатор сильный, а recovery процесс — нет. Security Magazine в мае 2026 года описывает этот паттерн как один из четырёх ключевых identity gaps, которые атакующие эксплуатируют [26].

Правильный подход: уровень верификации при recovery должен соответствовать уровню верификации при первичной регистрации (NIST SP 800-63A, уровни IAL) [27]. Для привилегированных аккаунтов — требовать видеоидентификацию, аппаратный токен или другой out-of-band канал.

Вопросы безопасности: метод, который давно пора упразднить

Вопросы безопасности ("Девичья фамилия матери", "Кличка первого питомца") кажутся интуитивными, но исследования давно показали их несостоятельность.

Исследование Bonneau et al. (2015), упоминаемое в академическом анализе recovery-механизмов MFA [4]:

1. 37% пользователей лгут при ответе на вопросы безопасности.
2. 40% не помнят своих ответов, когда они действительно нужны.
3. В более ранних работах Schechter et al. (2009) установили, что в 17% случаев знакомые пользователя могут угадать ответ.

С точки зрения безопасности это означает: вопросы либо легко угадать (публичная информация из социальных сетей), либо пользователи их забывают, либо намеренно вводят ложные данные — что превращает этот механизм в ненадёжный с обеих сторон.

NIST SP 800-63B-4 не рекомендует использовать knowledge-based authentication (KBA) в качестве метода восстановления. OWASP прямо указывает, что вопросы безопасности должны поддерживать "достаточно случайные ответы" — что на практике означает либо очень высокую энтропию вопроса, либо отказ от этого подхода в пользу более надёжных механизмов [20].

MFA recovery: слабое место сильной аутентификации

Если сброс пароля сам по себе уже чувствительная точка, то восстановление доступа при потере MFA-устройства — ещё более уязвимый узел.

Исследование "We've Disabled MFA for You" (ACM CCS 2023) провело анализ recovery-механизмов MFA у 22 популярных сервисов [4]. Выводы неутешительные: большинство платформ либо предлагают небезопасные fallback-методы (SMS, security questions), либо процедура настолько сложна, что пользователи её не проходят.

Ключевые проблемы:

1. Backup-коды генерируются, но пользователи их не сохраняют (или теряют).
2. SMS-коды для восстановления уязвимы к SIM-swap: по данным 2024 года, SIM-swap fraud вырос на 1055% [28].
3. Recovery через email возвращает зависимость от безопасности email-аккаунта.
4. При MFA fatigue attacks (MFA bombing) пользователи одобряют запросы из-за усталости от уведомлений — Lapsus$ использовали именно этот метод [29].

Cisco Talos установили, что в 2024 году половина их incident response-случаев была связана с обходом MFA [30].

По NIST SP 800-63B-4, recovery от утраты аутентификатора должен проходить через тот же уровень identity assurance, что и первичная регистрация [3]. На практике это означает: для аккаунтов с AAL2/AAL3 нельзя предлагать SMS-верификацию как fallback для восстановления потерянного TOTP-приложения.

Passkeys и FIDO2: смена парадигмы и новые вызовы recovery

Passkeys (FIDO2/WebAuthn) действительно решают ключевую проблему: они не могут быть фишингованы, не используются повторно между сервисами, не хранятся на сервере как секрет. По данным FIDO Alliance, 53% пользователей включили passkeys хотя бы на одном аккаунте в 2024 году [31]. NIST SP 800-63B-4 официально признаёт synced passkeys как соответствующие уровню AAL2 [3].

Однако passkeys не устраняют необходимость в recovery — они переносят её на другой уровень. Если пользователь потерял все устройства с passkey, нужен fallback. И здесь возникает риск: неправильно реализованный recovery-поток для passkeys может вернуть все старые уязвимости через "запасной вход".

Ключевые принципы безопасного recovery для passkeys [7]:

1. Регистрация нескольких ключей на разных устройствах — основная рекомендация FIDO Alliance.
2. Recovery должен избегать "phishable options" (email-ссылки, SMS-коды) — иначе passkey-аккаунт можно захватить через старые векторы.
3. Адаптивная аутентификация: если recovery идёт с известного устройства — требования могут быть мягче; с нового и неизвестного — строже.
4. Стандарт Credential Exchange Protocol (разрабатывается FIDO Alliance) должен стандартизировать безопасную передачу passkeys между платформами [32].

Как отметил Techopedia в 2025 году, Dashlane строят свою FIDO2-реализацию так, чтобы их план восстановления не реинтродуцировал старые риски вроде email-ссылок для сброса [7].

Чек-лист: безопасный сброс пароля и recovery

Генерация и управление токенами

1. Использовать CSPRNG для генерации токенов (не Math.random(), не UUID на основе timestamp).
2. Длина токена — минимум 20 байт в бинарном представлении, закодированных в URL-safe base64.
3. TTL токена — 15–60 минут в зависимости от чувствительности системы.
4. Один токен = один пользователь = одно использование. Инвалидировать немедленно после применения.
5. Хранить только хеш токена в базе (SHA-256 или argon2id); сравнивать хеши, не сырые значения.
6. При повторном запросе на сброс — инвалидировать все предыдущие токены для этого пользователя.

Формирование reset-ссылки

1. Базовый URL брать из конфигурации приложения — никогда из заголовка Host запроса.
2. Добавить заголовок Referrer-Policy: no-referrer на страницу с формой сброса.
3. Предпочтительно: передавать токен через POST-тело, не в URL (чтобы не попасть в access logs, browser history, Referer).
4. Реализовать Content-Security-Policy и HSTS на страницах recovery.

Защита от перечисления и брутфорса

1. Одинаковое сообщение в ответ на запрос сброса для существующих и несуществующих аккаунтов.
2. Одинаковое время ответа (async-обработка или искусственная задержка до фиксированного значения).
3. Rate limiting: ограничение по аккаунту, по IP, по временному окну.
4. При превышении порога запросов — CAPTCHA или временная блокировка.

Сессии и состояние после сброса

1. После успешного сброса — инвалидировать все активные сессии пользователя (или как минимум предложить это явно).
2. Новый session ID после каждого логина.
3. Не выполнять автоматический вход после сброса — требовать явной аутентификации.
4. Уведомить пользователя о сбросе по email (отдельное письмо, не с токеном).

Helpdesk и операционные процедуры

1. Верификация при identity-reset через helpdesk должна соответствовать уровню IAL первичной регистрации.
2. Для привилегированных аккаунтов — только out-of-band верификация (видеозвонок, аппаратный токен).
3. Все запросы на сброс через helpdesk должны логироваться и ревьюиться.
4. Включить аудит изменений email-адресов на аккаунте — аномальные изменения должны триггерить алерт.

Для passkeys

1. Требовать регистрацию минимум двух passkeys на разных устройствах.
2. Recovery-поток должен избегать SMS/email как единственного fallback.
3. Внедрить адаптивную аутентификацию: строже при recovery с нового устройства.

Типичные ошибки и как их не допустить

Ошибка первая: единственный канал recovery — email. Если email-аккаунт скомпрометирован, скомпрометированы и все сервисы с recovery через этот email. Решение: out-of-band каналы для привилегированных аккаунтов.

Ошибка вторая: токен в URL без Referrer-Policy. Любой сторонний скрипт на странице получает токен. Решение: проверить наличие заголовка, перейти на POST.

Ошибка третья: не хешировать токены в базе. При SQL injection или дампе базы атакующий получает все действующие reset-токены. Решение: хранить только SHA-256(token).

Ошибка четвёртая: не инвалидировать старые токены при повторном запросе. Пользователь делает несколько попыток, у атакующего есть несколько активных токенов. Решение: при новом запросе помечать все предыдущие токены пользователя как использованные.

Ошибка пятая: доверять Host-заголовку при генерации reset-ссылки. Это password reset poisoning. Решение: жёстко задать APP_BASE_URL в конфигурации.

Ошибка шестая: разное время ответа для существующих и несуществующих пользователей. Это user enumeration через timing. Решение: async-обработка или time.sleep() до фиксированного значения.

Ошибка седьмая: не инвалидировать сессии после сброса. Атакующий с украденной сессией сохраняет доступ. Решение: session.invalidateAll() после успешного сброса.

Инциденты как учебный материал

Помимо CVE-2023-7028 в GitLab, история знает ряд показательных инцидентов, связанных с недостатками в логике сброса пароля:

На HackerOne задокументированы сотни подобных репортов: утечка токена через Referer в Toyota (bug bounty report от 2019 года), password reset poisoning через Host header в Shopify-приложении (GHSA-7m2v-x7rg-5hm5) [19] и другие. Большинство из них — не экзотика, а последствие шаблонных ошибок.

Показателен и паттерн со Snowflake в 2024 году: десятки крупных компаний пострадали от компрометации учётных данных именно потому, что MFA не было принудительно включено, а recovery-флоу не требовал дополнительной верификации [29].

Тренды: куда движется аутентификация

Рынок passwordless authentication растёт с прогнозируемым объёмом $22 млрд в 2025 году и $61 млрд к 2032 году [7]. NIST SP 800-63B-4 (июль 2025) официально признаёт synced passkeys как AAL2-compatible [3]. ЕС в рамках eIDAS 2.0 (май 2024) мандатирует для всех государств-членов создание European Digital Identity Wallet [33]. Ряд юрисдикций (UAE, Индия, Филиппины) устанавливают жёсткие дедлайны по отказу от SMS-OTP [32].

Однако пароли не исчезнут в одночасье. Passkeys требуют поддержки устройства и браузера, которой нет у всех пользователей. Корпоративные системы с legacy-инфраструктурой продолжат использовать пароли на горизонте нескольких лет. По оценкам, менее 10% рабочих логинов полностью переведены на passwordless по состоянию на 2025 год [34].

Это значит: recovery-флоу на основе email/SMS будет существовать ещё долго, и его нужно делать правильно — независимо от того, насколько passkeys популярны в маркетинговых материалах.

Практический вывод: где именно ломается безопасность

Сброс пароля — это не "вспомогательная фича". Это полноценная точка входа с отдельной поверхностью атаки, требующей собственного threat model.

Большинство уязвимостей в этой области — не результат сложных атак, а следствие шаблонных ошибок: доверие к Host-заголовку, хранение токенов в открытом виде, разные времена ответа, неинвалидированные сессии. Эти ошибки хорошо известны, задокументированы в OWASP и регулярно находятся в bug bounty программах — но воспроизводятся снова и снова.

Проблема усугубляется в командах, где AI ускорил разработку: LLM генерирует рабочий reset-флоу быстро, но "рабочий" не равно "безопасный". Генерируемый код часто не учитывает Referrer-Policy, не хеширует токены, не инвалидирует сессии — потому что задача звучала как "реализуй сброс пароля", а не "реализуй безопасный сброс пароля с учётом OWASP Forgot Password Cheat Sheet".

Именно здесь имеет смысл дополнительный слой контроля до merge: проверка PR на наличие чувствительных паттернов в логике аутентификации и recovery — не после выкатки в прод, а на этапе ревью изменений. HighVibe решает эту задачу для команд, где AI-кодинг уже ускорил разработку, но контроль безопасности изменений не вырос с той же скоростью.

Источники

[1] Infosecurity Magazine — "Rapid Growth of Password Reset Attacks Boosts Fraud, Account Takeovers" — https://www.infosecurity-magazine.com/news/password-reset-attacks-fraud/

[2] OWASP — "Forgot Password Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

[3] NIST — "SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management" (July 2025) — https://doi.org/10.6028/NIST.SP.800-63B-4

[4] Amft et al. — "We've Disabled MFA for You: An Evaluation of the Security and Usability of Multi-Factor Authentication Recovery Deployments" (ACM CCS 2023) — https://arxiv.org/pdf/2306.09708

[5] The Hacker News — "CISA Warns of Active Exploitation of Severe GitLab Password Reset Vulnerability (CVE-2023-7028)" — https://thehackernews.com/2024/05/cisa-warns-of-active-exploitation-of.html

[6] Security Magazine — "Reframing MFA Bypass: Four Identity Gaps Attackers Exploit" (2026) — https://www.securitymagazine.com/articles/102304-reframing-mfa-bypass-four-identity-gaps-attackers-exploit

[7] Techopedia — "FIDO2 & Passkeys: The Future of Passwordless Authentication" — https://www.techopedia.com/passwordless-authentication-fido2-passkeys

[8] AuthX — "Account Takeover Statistics 2025: Key Trends & Insights" — https://www.authx.com/blog/account-takeover-fraud-statistics-insights/

[9] SpyCloud — "Cybersecurity Industry Statistics: ATO, Ransomware, Breaches & Fraud" — https://spycloud.com/blog/cybersecurity-industry-statistics-account-takeover-ransomware-data-breaches-bec-fraud/

[10] Anti-Malware.ru — "Компании привыкли доверять сбросу пароля. Злоумышленники этим пользуются" (2026) — https://www.anti-malware.ru/news/2026-04-24-111332/49824

[11] PortSwigger Web Security Academy — "Password Reset Poisoning" — https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning

[12] GitHub Advisory Database — "Host header injection in the password reset · CVE-2024-23648 (Pimcore)" — https://github.com/advisories/GHSA-mrqg-mwh7-q94j

[13] GitHub Advisory Database — "CouchAuth host header injection vulnerability leaks the password reset token (GHSA-fqh6-6h6c-366m)" — https://github.com/advisories/GHSA-fqh6-6h6c-366m

[14] GitHub Security Advisories — "Kanboard: Password Reset Poisoning via Host Header Injection (GHSA-2ch5-gqjm-8p92)" — https://github.com/kanboard/kanboard/security/advisories/GHSA-2ch5-gqjm-8p92

[15] OWASP Testing Guide — "Testing for Weak Password Change or Reset Functionalities" — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities

[16] GitHub Security Advisories — "Directus Vulnerable to User Enumeration via Password Reset Timing Attack (CVE-2026-26185)" — https://github.com/directus/directus/security/advisories/GHSA-jr94-gj3h-c8rf

[17] Django Project Issue Tracker — "CVE-2024-39329: Account enumeration through timing attack in password verification" — https://code.djangoproject.com/ticket/20760

[18] GitLab Advisory Database — "CVE-2024-47057: Mautic allows user name enumeration due to response time difference on password reset form" — https://advisories.gitlab.com/pkg/composer/mautic/core/CVE-2024-47057/

[19] OSV.dev — "GHSA-7m2v-x7rg-5hm5: silverstripe/framework vulnerable to user enumeration via timing attack" — https://osv.dev/vulnerability/GHSA-7m2v-x7rg-5hm5

[20] OWASP — "Secure Coding Practices Quick Reference Guide" — https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist

[21] Undercode Testing — "The Session Fixation Flaw: Why Your Password Reset Is Secretly Useless" — https://undercodetesting.com/the-session-fixation-flaw-why-your-password-reset-is-secretly-useless/

[22] GitHub Advisory Database — "GHSA-99hm-86h7-gr3g: zenml-io/zenml does not expire the session after password reset" — https://github.com/advisories/GHSA-99hm-86h7-gr3g

[23] OWASP Top 10:2025 — "A07 Authentication Failures" — https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/

[24] SecurityWeek — "Thousands of GitLab Instances Unpatched Against Critical Password Reset Bug" — https://www.securityweek.com/thousands-of-gitlab-instances-unpatched-against-critical-password-reset-bug/

[25] Help Net Security — "Critical GitLab flaw allows account takeover without user interaction, patch quickly! (CVE-2023-7028)" — https://www.helpnetsecurity.com/2024/01/12/cve-2023-7028/

[26] Security Magazine — "Reframing MFA Bypass: Four Identity Gaps Attackers Exploit" — https://www.securitymagazine.com/articles/102304-reframing-mfa-bypass-four-identity-gaps-attackers-exploit

[27] NIST — "SP 800-63A: Digital Identity Guidelines: Identity Proofing and Enrollment" — https://csrc.nist.gov/publications/detail/sp/800/63/a/final

[28] Infisign — "Account Takeover Fraud Statistics: Insights for 2026" — https://www.infisign.ai/blog/account-takeover-fraud-statistics-insights

[29] Obsidian Security — "MFA Bypass: Attack Techniques and Defense Strategies" — https://www.obsidiansecurity.com/blog/mfa-bypass-attacks-defense-strategies

[30] Astra Security — "MFA Bypass Risks: What You Need to Know in 2026" — https://www.getastra.com/blog/dast/mfa-bypass-risks/

[31] FIDO Alliance — "Passkeys" — https://fidoalliance.org/passkeys/

[32] Safe Pass Guru — "Passkeys and the Passwordless Future: FIDO2 Explained" (2026) — https://safepass.guru/articles/2026032103-passkeys-fido2-explained/

[33] MojoAuth — "Passkeys Handbook 2025" — https://mojoauth.com/white-papers/passkeys-passwordless-authentication-handbook/

[34] DeepStrike — "70+ Password Statistics 2026: What the Numbers Really Say" — https://deepstrike.io/blog/password-statistics-2025