[Информационная безопасность] Шпаргалки по безопасности: сброс пароля (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
07-Дек-2020 18:30

Цитировать

Комментарий переводчикаРешили продолжить перевод шпаргалок по безопасности от OWASP на фоне массовых восстановлений паролей послеутечки базы данных у сервиса rzd-bonus.ru.ВведениеДля того, чтобы реализовать надлежащую систему управления пользователями, в нее обычно внедрена служба по восстановлению пароля, которая позволяет пользователям сделать сброс пароля в случае его утери. Несмотря на то, что данная функциональность выглядит довольно понятной и простой, она является частым источником уязвимостей, одна из таких – подбор имени пользователя. Следующие небольшие инструкции можно использовать в качестве краткой памятки в случае утери пароля:

возвращать одинаковое сообщение как существующим, так и несуществующим учетным записям;
убедиться, что время, которое будет затрачено на ответ пользователю, является одинаковым;
использовать сторонний канал для сброса пароля;
использовать URL токены для простой и быстрой реализации;
убедиться, что сгенерированные токены или коды:
- генерируются случайным образом с использованием безопасного криптографического метода;
- невозможно перебрать за разумное время методом полного перебора;
- обеспечено надежное хранение;
- одноразовое использование и срок жизни истекает через определенный период.
Эта шпаргалка посвящена сбросу паролей пользователей.

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

вернуть одинаковое сообщение как существующим, так и несуществующим учетным записям;
убедиться, что запрос возвращается через одинаковое время для того, чтобы избежать перебора существующих учетных записей злоумышленником;
реализовать защиту от автоматических проверок, например, CAPTCHA, ограничение скорости запросов или другие методы;
использовать классические методы защиты, например, защита от SQL-инъекций, использование валидации на ввод данных и др.

Пользователь сбрасывает пароль Единожды подтверждая свою личность токеном (через почту) или кодом (через SMS), пользователь должен иметь возможность сменить пароль на другой, более безопасный.

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

Методы сброса пароляЧтобы пользователь мог запросить сброс пароля, вам понадобится способ, чтобы идентифицировать пользователя, или способ, чтобы связаться с ним через сторонний канал.Это может быть сделано любым из следующих методов:

токены URL;
PIN-коды;
автономные методы;
контрольные вопросы.

Эти методы можно использовать вместе, чтобы обеспечить большую степень уверенности в том, что пользователь является тем, кем он себя называет. Несмотря ни на что, вы должны убедиться, что у пользователя всегда есть способ восстановить свою учетную запись, даже если для этого необходимо обратиться в службу поддержки и подтвердить свою личность сотрудникам.Общие практикиВажно применять передовые методы безопасности для идентификаторов сброса (токены, коды, PIN-коды и т. д.). Некоторые моменты не относятся к автономным методам, например, ограничение время жизни. Все токены и коды должны:

быть сгенерированы криптографически безопасным генератором случайных чисел;
также можно использовать веб-токены JSON (JWT) вместо случайных токенов, хотя это может привести к дополнительной уязвимости;
достаточно долго подбираемы, чтобы защитить себя от атак полного перебора;
быть связаны с уникальным пользователем в базе данных;
утратить силу после того, как они были использованы;
храниться безопасным способом.

Токены URLТокены URL-адреса передаются в строке запроса URL-адреса и обычно отправляются пользователю по электронной почте. Процесс выглядит следующим образом:

Создайте токен для пользователя и присоедините его к строке запроса URL.
Отправьте этот токен пользователю по электронной почте.
Не полагайтесь на заголовок Host при создании URL-адресов сброса, чтобы избежать инъекции HTTP-заголовка. URL-адрес должен быть либо жестко зашит, либо должен быть проверен в белом списке доверенных доменов.
Убедитесь, что URL-адрес использует HTTPS.
Пользователь получает электронное письмо и переходит к URL-адресу с прикрепленным токеном.
Убедитесь, что на странице сброса пароля добавлен тег Referrer-Policy со значением «noreferrer» (прим. переводчика: а такое до сих пор случается), чтобы избежать его утечки.
Внедрите соответствующую защиту, чтобы предотвратить перебор токенов в URL-адресе, например ограничение скорости запросов.
При необходимости выполните любые дополнительные шаги проверки, например, попросите пользователя ответить на контрольные вопросы.
Позвольте пользователю создать новый пароль и подтвердить его. Убедитесь, что применяется та же политика паролей, что и в другом месте приложения.

Примечание. Токены URL могут следовать тому же поведению, что и PIN, путем создания ограниченного сеанса из токена. Решение должно приниматься исходя из потребностей и опыта разработчика.PIN-кодыPIN-коды — это числа (от 6 до 12 цифр), которые отправляются пользователю через сторонний канал, например SMS.

Создайте PIN-код.
Отправьте его пользователю по SMS или другим способом.
Разделяйте PIN пробелами, чтобы упростить чтение и ввод пользователем.
Затем пользователь должен ввести PIN-код вместе со своим именем пользователя на странице сброса пароля.
Создайте ограниченный сеанс для этого PIN-кода, который позволит пользователю сбросить свой пароль.
Позвольте пользователю создать новый пароль и подтвердить его. Убедитесь, что применяется та же политика паролей, что и во всем приложении.

Автономные методыАвтономные методы отличаются от других тем, что позволяют пользователю сбрасывать свой пароль без запроса специального идентификатора (например, токена или PIN-кода) из серверной части. Однако серверная часть по-прежнему должна проводить аутентификацию, чтобы гарантировать, что запрос является неподдельным. Автономные методы предоставляют определенный идентификатор либо при регистрации, либо когда пользователь желает его настроить.Эти идентификаторы должны храниться в автономном режиме и в защищенном виде (например, менеджеры паролей), а серверная часть должна должным образом следовать общим правилам безопасности. Некоторые реализации построены на аппаратных токенах OTP, сертификатах или любой другой реализации, которая может использоваться внутри предприятия. Резервные кодыРезервные коды должны быть предоставлены пользователю после регистрации, где пользователь должен хранить их в автономном режиме в безопасном месте (например, менеджер паролей). Компании, которые используют данный метод — это Google, GitHub и Auth0.При реализации этого метода следует соблюдать следующие правила:

минимальная длина - 8 цифр, 12 цифр - для повышенной безопасности;
у пользователя должно быть несколько кодов восстановления в любой момент времени, чтобы гарантировать, что один из них работает (большинство сервисов предоставляют пользователю десять резервных кодов);
следует реализовать процесс, позволяющий пользователю аннулировать все существующие коды восстановления в случае их взлома третьей стороной;
следует реализовать ограничение скорости запросов и другие средства защиты, чтобы злоумышленник не смог подобрать коды резервных копий.

Контрольные вопросыКонтрольные вопросы не должны использоваться в качестве единственного механизма для сброса паролей, поскольку их ответы часто легко угадываются или доступны злоумышленникам. Однако они могут обеспечить дополнительный уровень безопасности в сочетании с другими методами, описанными в этой шпаргалке.
===========
Источник:
habr.com
===========
===========
Автор оригинала: OWASP
===========Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_owasp, #_informatsionnaja_bezopasnost (информационная безопасность), #_paroli (пароли), #_bezopasnost_parolej (безопасность паролей), #_blog_kompanii_owasp (
Блог компании OWASP
), #_blog_kompanii_akribija (
Блог компании Акрибия
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:18
Часовой пояс: UTC + 5