Как защитить механизмы аутентификации

В этом разделе мы расскажем, как предотвратить появление некоторых уязвимостей в ваших механизмах аутентификации.

Аутентификация — сложная тема, и, как мы показали, к сожалению, слабые места и изъяны легко просачиваются в реализацию. Перечислить все возможные меры для защиты ваших веб‑сайтов очевидно невозможно. Тем не менее, есть несколько общих принципов, которых следует придерживаться всегда.

Бережно обращайтесь с учётными данными

Даже самые надёжные механизмы аутентификации неэффективны, если вы по неосторожности раскрываете действительные учётные данные злоумышленнику. Само собой разумеется, что нельзя отправлять какие‑либо данные для входа по нешифрованным соединениям. Даже если вы внедрили HTTPS для запросов на вход, убедитесь, что вы принудительно перенаправляете любые попытки обращения по HTTP на HTTPS.

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

Не рассчитывайте на пользователей в вопросах безопасности

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

Самый очевидный пример — внедрить эффективную политику паролей. Некоторые традиционные политики не работают, потому что люди «впихивают» свои предсказуемые пароли в рамки политики. Вместо этого может быть эффективнее реализовать простой проверяющий модуль паролей, который позволяет пользователям экспериментировать с паролями и даёт обратную связь об их надёжности в реальном времени. Популярный пример — JavaScript‑библиотека zxcvbn, разработанная Dropbox. Разрешая только те пароли, которые высоко оценивает проверяющий модуль, вы можете гораздо эффективнее принуждать к использованию безопасных паролей, чем с помощью традиционных политик.

Предотвращайте перечисление имён пользователей

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

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

Реализуйте надёжную защиту от перебора

Учитывая, насколько просто сконструировать атаку перебором, крайне важно предпринять шаги, чтобы предотвратить или хотя бы затруднить любые попытки перебора логинов. Одним из более эффективных методов является строгий лимит частоты запросов (rate limiting), основанный на IP‑адресе. Это должно включать меры, предотвращающие манипулирование злоумышленниками своим видимым IP‑адресом. В идеале после достижения определённого порога вы должны требовать прохождения CAPTCHA при каждой попытке входа.

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

Тройная проверка логики верификации

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

Не забывайте о сопутствующей функциональности

Убедитесь, что вы сосредоточены не только на центральных страницах входа, не упуская из виду дополнительную функциональность, связанную с аутентификацией. Это особенно важно в случаях, когда злоумышленник может свободно зарегистрировать собственный аккаунт и исследовать эту функциональность. Помните, что сброс или изменение пароля — столь же валидная поверхность атаки, как основной механизм входа, и, следовательно, она должна быть столь же надёжной.

Реализуйте корректную многофакторную аутентификацию

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

SMS‑основанная 2FA технически проверяет два фактора (то, что вы знаете, и то, что у вас есть). Однако потенциальные злоупотребления, например через SIM‑сваппинг, делают эту систему ненадёжной.

В идеале 2FA должна быть реализована с использованием специализированного устройства или приложения, которое генерирует код подтверждения непосредственно. Поскольку они специально создаются для обеспечения безопасности, они обычно более надёжны. И наконец, как и в основной логике аутентификации, убедитесь, что логика проверок 2FA корректна и не может быть легко обойдена.