Аутентификация: вход, факторы и восстановление
Все пути получения учетной записи проходят серверную проверку подлинности и защиту от перебора. Восстановление пароля или смена фактора не могут быть более слабым обходом основного входа.
Плохо
Основной вход требует MFA, но reset по email из body сразу меняет пароль.
Пароли хранятся как SHA-256; лимит попыток проверяется только в UI.
Хорошо
Серверный authentication framework / доверенный IdP.
Вход → bounded attempts → проверка фактора → новая сессия.
Recovery → одноразовый ограниченный token → атомарное потребление.
Sensitive account change → повторная аутентификация + уведомление.
Успех/отказ журналируются без пароля, OTP и recovery token.
Почему это важно
Аутентификация устанавливает субъект, но не права на объект. Хеш общего назначения не предназначен для замедления перебора паролей. Надежный login теряет смысл, если legacy API, support flow или повторно используемая reset-ссылка позволяют получить ту же учетную запись без нужного подтверждения.
Когда применять
Для интерактивного входа пользователей; machine-to-machine credentials имеют отдельный профиль. Перечислите login, registration, recovery, MFA enrollment/removal, account linking и служебные обходы. Проверка выполняется backend/IdP; локальный флаг браузера не является результатом. Используйте поддерживаемый framework/IdP, TLS и одинаковую политику на web/mobile/API. В этом профиле административный доступ и управление платежами требуют MFA; остальные роли выбираются анализом риска. Для OIDC действует integrations.oauth.
Если приложение хранит пароли, используйте password-hashing API с индивидуальной солью, предпочтительно Argon2id; параметры выбираются не ниже актуального принятого OWASP-профиля и проверяются под нагрузкой. Не храните plaintext/обратимо зашифрованный пароль и не используйте простой SHA-256. Разрешите passphrases и password managers; задайте minimum/maximum длину без скрытого усечения, запрет известных скомпрометированных паролей, отказ от произвольной периодической смены без основания. Числа политики должны быть записаны в проекте, не оставаться словами «достаточно надежный».
Предел попыток учитывает account и общий источник/бюджет, действует на всех экземплярах и не позволяет легко навсегда заблокировать жертву. Ответы login/recovery не раскрывают наличие учетной записи через текст/status и очевидное различие обработки. Recovery token случаен, связан с пользователем/назначением, имеет срок и атомарно используется один раз; он не заменяет необходимый второй фактор без отдельной безопасной recovery-политики. Смена email/пароля/MFA требует повторного подтверждения, уведомления по доверенному каналу и политики отзыва сессий.
Кто что делает
Человек
Выбирает уровни аутентификации, численные ограничения, безопасное recovery и владельца исключений.
AI-агент
Перечисляет все auth pathways, использует проверенный framework и проверяет replay/конкуренцию recovery без журналирования секретов.
Как проверить у себя
-
Верные факторы действующей учетной записи → login → сервер создает новую сессию только после полной проверки → auth event без credential.
-
Массовые неверные попытки через разные API/instances или неизвестный account → вход/recovery → общий лимит действует, публичные отказы не раскрывают account → controlled negative fixtures.
-
Reset token истек, использован повторно/параллельно, либо смена MFA без reauthentication → запрос → не более одного допустимого восстановления, обход фактора отвергнут → состояние token/account/session.
Первоисточники
Дата проверки отражает содержательную сверку. Синхронизация сайта не обновляет её автоматически.