Аутентификация отвечает на вопрос «кто ты». Ошибки здесь дают атакующему чужой аккаунт целиком, поэтому на собесе AppSec разбирают вход, сессии, сброс пароля и OAuth.
Пароли
Современные рекомендации (NIST SP 800-63B) ушли от «сложных» правил:
- Важна длина, а не набор символов: минимум 8, а в новой редакции 15 для паролей без второго фактора. Разрешать длинные пароли и фразы (64 символа и больше), любые символы.
- Проверять по базам утёкших паролей (например через k-anonymity API Have I Been Pwned) и словарям.
- Не требовать периодической смены без признаков компрометации: люди начинают делать
Пароль1,Пароль2. - Не использовать подсказки и «секретные вопросы».
- Хранить только как медленный хеш с солью (Argon2id, bcrypt, scrypt), об этом в модуле про криптографию.
Перебор и credential stuffing
- Перебор (brute force): много паролей к одному аккаунту.
- Password spraying: один популярный пароль ко многим аккаунтам, обходит блокировку по аккаунту.
- Credential stuffing: пары логин-пароль из чужих утечек. Самая массовая атака на вход.
Защита: ограничение частоты по аккаунту и по IP, прогрессивные задержки, CAPTCHA при подозрительной активности, проверка утёкших паролей, MFA, уведомления о входе с нового устройства. Жёсткая блокировка аккаунта после N попыток позволяет атакующему заблокировать любого пользователя (DoS), поэтому чаще используют временную блокировку и задержки.
Перечисление аккаунтов: разные ответы «нет такого пользователя» и «неверный пароль», разное время ответа, разные сообщения при регистрации и сбросе пароля. Ответ должен быть одинаковым: «Если аккаунт существует, мы отправили письмо».
MFA
- TOTP (приложение-аутентификатор, RFC 6238): код из общего секрета и текущего времени. Хорошо, но фишинговая страница может переслать код в реальном времени.
- SMS: лучше, чем ничего, но уязвимы к перевыпуску SIM и перехвату.
- Push-подтверждение: уязвимо к «усталости от push» (атакующий шлёт запросы, пока жертва не нажмёт), помогает сопоставление числа.
- WebAuthn и passkeys: ключ привязан к домену, поэтому устойчив к фишингу. Лучший вариант.
Сессии
- Идентификатор сессии: случайный, не меньше 128 бит энтропии, генерируется сервером.
- Перевыпускать идентификатор при входе и смене привилегий, иначе возможна фиксация сессии (атакующий заранее подсовывает свой id).
- Cookie:
HttpOnly,Secure,SameSite=LaxилиStrict, префикс__Host-(только Secure, без Domain, Path=/). - Тайм-ауты: по бездействию и абсолютный.
- Выход и смена пароля инвалидируют сессию на сервере, а не только удаляют cookie. Хорошо дать список активных сессий и кнопку «выйти везде».
Сброс пароля
- Токен случайный, одноразовый, живёт 15-60 минут, в базе хранится его хеш.
- Ссылку строить из конфигурации, а не из заголовка
Hostзапроса: иначе атакующий получит ссылку со своим доменом (poisoning ссылки сброса). - После сброса завершить все сессии и уведомить пользователя.
- Не раскрывать, существует ли аккаунт.
OAuth 2.0 и OpenID Connect
- OAuth 2.0 про делегирование доступа (приложение получает токен на действия от имени пользователя). OIDC добавляет аутентификацию: ID-токен с информацией о пользователе.
- Для веба, SPA и мобильных: Authorization Code + PKCE. Implicit flow и Resource Owner Password Credentials устарели и не рекомендуются (OAuth 2.0 Security BCP, OAuth 2.1).
stateзащищает от CSRF на callback,nonceв OIDC от повторного использования ID-токена.redirect_uriпроверяется точным совпадением с зарегистрированным.- ID-токен проверять полностью: подпись,
iss,aud,exp,nonce.
Частые ошибки
- Разные сообщения для «нет пользователя» и «неверный пароль».
- Сессия не перевыпускается при входе.
- Logout удаляет только cookie.
- Токен сброса без срока жизни или многоразовый.
- Implicit flow в новом SPA.
Что спросят на собесе
- Как защитить вход от credential stuffing.
- Какие требования к паролям правильные в 2026 году.
- Что такое фиксация сессии и как её предотвратить.
- Как безопасно реализовать сброс пароля.
- Почему passkeys устойчивы к фишингу, а TOTP нет.
- Что такое PKCE и зачем он SPA.