C6: Внедрение цифровой идентификации

Описание

Цифровая идентификация — это уникальное представление пользователя (или любого другого объекта) при онлайн-транзакциях. Аутентификация — это процесс подтверждения того, что человек или сущность является тем, кем представляется. Управление сессиями — это процесс, с помощью которого сервер контролирует состояние аутентификации пользователя, чтобы он мог продолжать пользоваться системой без повторной аутентификации. Специальное издание NIST 800-63B: Руководство по цифровой идентификации (Аутентификация и управление жизненным циклом) содержит подробные рекомендации по реализации требований к цифровой идентификации, аутентификации и управлению сессиями.

Ниже приведены некоторые рекомендации по безопасной реализации.

Уровни аутентификации

NIST 800-63b описывает три уровня обеспечения аутентификации (AAL). Уровень 1 зарезервирован для приложений пониженного риска, которые не содержат персональных или иных личных данных. Для первого уровня достаточно однофакторной аутентификации, обычно реализованной через использование пароля.

Уровень 1: Пароли

Пароли на самом деле важны. К ним необходимо применять определенные политики, их хранение должно быть безопасным, в некоторых случаях у пользователя должна иметься возможность сброса пароля.

Требования к паролям

Пароли должны, как минимум, соответствовать следующим требованиям:

  • состоять из 8 символов, если используется многофакторная аутентификация (МФА) и другие методы контроля. Если использование МФА не представляется возможным, длину пароля необходимо увеличить, как минимум, до 10 символов;
  • все печатаемые символы ASCII, а также символ пробела, должны быть разрешены для использования в запоминаемых секретах;
  • старайтесь использовать длинные пароли и кодовые фразы;
  • откажитесь от требований к сложности пароля, поскольку их эффективность весьма ограниченна. Вместо этого рекомендуется использовать МФА или более длинные пароли;
  • убедитесь в том, что используемые пароли не находятся в списке распространенных и ранее скомпрометированных паролей. Можно настроить блокировку паролей из топ-1000 или топ-10000 наиболее часто используемых паролей, которые соответствуют указанным выше требованиям к длине и присутствуют в списках скомпрометированных паролей. Самые распространенные пароли можно найти, перейдя по следующей ссылке: https://github.com/danielmiessler/SecLists/tree/master/Passwords

Реализация механизма безопасного восстановления пароля

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

Более подробную информацию см. в Памятке по забытым паролям и Памятке по выбору и использованию контрольных вопросов.

Реализация безопасного хранения паролей

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

Пример хранения паролей в PHP

Ниже приведен пример безопасного хеширования паролей в PHP с помощью функции password_hash() (доступна, начиная с версии 5.5.0), в которой по умолчанию используется алгоритм bcrypt. В примере используется фактор трудоемкости равный 15.

<?php
$cost = 15;
$password_hash = password_hash("secret_password", PASSWORD_DEFAULT, ["cost" => $cost] );
?>

Более подробную информацию см. в Памятке OWASP по хранению паролей.

Уровень 2: Многофакторная аутентификация (МФА)

Уровень 2 (NIST 800-63b) зарезервирован для приложений повышенного риска, которые содержат «подтвержденные персональные или иные личные данные, доступные онлайн». На 2-м уровне AAL требуется многофакторная аутентификация, например, одноразовые пароли или другие формы МФА.

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

  • чего-то, известного пользователю — пароль или ПИН-код;
  • чего-то, принадлежащего пользователю — токен или телефон;
  • чего-то, являющегося частью пользователя — биометрические данные, например, отпечаток пальца.

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

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

Уровень 3: Аутентификация на основе шифрования

Уровень 3 (NIST 800-63b) используется, если вред от компрометации системы может нанести личный ущерб или ущерб государственным интересам, а также привести к значительным финансовым потерям и гражданским или уголовным правонарушениям. Для 3-го уровня требуется аутентификация, «основанная на подтверждении обладания ключом через протокол шифрования». Данный тип используется для обеспечения наивысшего уровня надежности аутентификации и, как правило, реализуется через аппаратные модули шифрования.

Управление сессиями

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

Создание и завершение сессий

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

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

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

Более подробную информацию см. в Памятке по управлению сессиями. Дополнительные требования к управлению сессиями содержатся в разделе 3 стандарта ASVS.

Куки-файлы браузеров

Куки-файлы используются для хранения идентификаторов сессий в веб-приложениях со стандартной схемой управления сессиями. Вот несколько советов по обеспечению безопасности при использовании куки-файлов:

  • когда куки-файлы используются для контроля сессий аутентифицированных пользователей, доступ к ним должен ограничиваться минимальным набором доменов и путей, а также они должны становиться недействительными сразу или вскоре после окончания срока действия сессии;
  • должен быть установлен флаг secure, обеспечивающий передачу данных только по безопасному каналу (TLS);
  • должен быть установлен флаг HttpOnly, предотвращающий доступ к куки-файлам с помощью JavaScript;
  • добавление атрибутов «samesite» к куки-файлам предотвращает отправку некоторыми современными браузерами куки-файлов с межсайтовыми запросами, а также обеспечивает защиту от межсайтовой подмены запросов и утечки данных.

Токены

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

JWT (веб-токены JSON)

Веб-токены JSON (JWT) представляют открытый стандарт (RFC 7519) компактного и самодостаточного способа безопасной передачи данных между участниками с помощью JSON-объектов. Эти данные могут быть проверены и подтверждены, поскольку имеют цифровую подпись. JWT-токены создаются во время аутентификации и проверяются сервером (или серверами) перед началом обработки данных.

После создания токены JWT, как правило, не сохраняются на сервере, а передаются клиенту. Целостность токена контролируется цифровой подписью, которая позволяет впоследствии проверить действительность и отсутствие модификаций JWT-токена.

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

Внимание!

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

Инструменты