Угроза восстановления и/или повторного использования аутентификационной информации

Угроза заключается в возможности доступа к данным пользователя в результате подбора (например, путём полного перебора или перебора по словарю) аутентификационной информации дискредитируемой учётной записи пользователя в системе, а также путём перехвата и повторного использования хэша пароля, для восстановления сеанса. Данная угроза обусловлена следующими недостатками:
значительно меньшим объёмом данных хеш-кода аутентификационной информации по сравнению с ней самой (время подбора хеш-кодов меньше времени полного перебора аутентификационной информации);
слабостями алгоритма расчёта хеш-кода, допускающими его повторное использование для выполнения успешной аутентификации.
Реализация данной угрозы возможна с помощью специальных программных средств, а также в некоторых случаях – «вручную».

• Внешний нарушитель с низким потенциалом
• Внутренний нарушитель с низким потенциалом

• Нарушение конфиденциальности

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

Для минимизации данной угрозы необходимо принять следующие меры:

1. Защита паролей:

• Хранение паролей в зашифрованном виде: Никогда не храните пароли в открытом виде. Используйте криптографические хеш-функции (например, Argon2, bcrypt, scrypt) для необратимого хеширования паролей.
• Использование “соли” (salt): Добавляйте уникальную “соль” к каждому паролю перед хешированием. “Соль” предотвращает атаки по словарю и радужным таблицам.
• Использование адаптивных хеш-функций: Использовать адаптивные хеш-функции, которые требуют значительных вычислительных ресурсов для взлома, что затрудняет атаки методом перебора.
• Регулярная смена паролей: Регулярно требовать от пользователей смены паролей, особенно для учетных записей с высокими привилегиями.
• Политика сложных паролей: Требовать от пользователей создания сложных паролей, состоящих из букв, цифр и специальных символов. Установите минимальную длину пароля.
• Запрет использования слабых паролей: Использовать списки распространенных и слабых паролей и запрещать их использование.
• Аутентификация без пароля: По возможности, рассмотреть возможность использования методов аутентификации без пароля, таких как биометрия, аппаратные ключи (например, YubiKey) или одноразовые пароли (OTP).

2. Защита от перехвата паролей:

• Использовать HTTPS: Обязательно использовать HTTPS для защиты трафика между клиентом и сервером, чтобы предотвратить перехват паролей в открытом виде.
• Защита от атак “человек посередине” (Man-in-the-Middle): Внедрить механизмы защиты от атак “человек посередине”, когда злоумышленник перехватывает и изменяет трафик между клиентом и сервером.
• Обучение пользователей: Обучать пользователей избегать фишинговых атак и не вводить свои пароли на подозрительных сайтах.

3. Многофакторная аутентификация (MFA):

• Внедрить MFA для всех пользователей: Требовать от пользователей использовать несколько факторов аутентификации (например, пароль + одноразовый код, биометрия, аппаратный ключ) для доступа к системе.
• Использовать различные методы MFA: Поддерживать различные методы MFA, чтобы пользователи могли выбрать наиболее удобный для себя.
• Усиленная защита процессов восстановления MFA: Реализовать надежные процессы восстановления доступа к MFA в случае утраты или компрометации одного из факторов.

4. Защита сессий:

• Генерация случайных и непредсказуемых идентификаторов сессий: Идентификаторы сессий должны быть достаточно длинными и случайными, чтобы их было сложно угадать.
• Срок действия сессий: Устанавливать ограниченный срок действия сессий и автоматически завершать сессии после определенного периода неактивности.
• Обновление идентификатора сессии при смене привилегий: Обновлять идентификатор сессии при каждом изменении привилегий пользователя (например, при входе в систему или при выполнении административных действий).
• Защита от угона сессий (session hijacking): Внедрить механизмы защиты от угона сессий, такие как проверка IP-адреса пользователя и использование HTTPOnly cookies.
• Использовать Secure и HTTPOnly cookies: Устанавливать атрибуты Secure и HTTPOnly для cookies сессий, чтобы защитить их от перехвата и XSS-атак.
• Завершение сессий при выходе: Обеспечить корректное завершение сессий при выходе пользователя из системы.

5. Защита токенов:

• Использовать токены с ограниченным сроком действия: Токены доступа (например, JWT) должны иметь ограниченный срок действия, чтобы снизить риск их использования после компрометации.
• Регулярно обновлять токены: Регулярно обновлять токены доступа, чтобы злоумышленник не мог использовать старый токен для получения доступа к системе.
• Хранить токены в безопасном месте: Хранить токены доступа на стороне клиента в безопасном месте, например, в защищенном хранилище браузера (например, localStorage или sessionstorage с атрибутом HTTPOnly).
• Использовать refresh tokens: Использовать refresh tokens для получения новых токенов доступа без необходимости повторной аутентификации пользователя.
• Revocation of tokens: Предоставить возможность отзыва токенов в случае их компрометации.

6. Биометрическая аутентификация:

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

7. Защита сертификатов:

• Хранение сертификатов в безопасном месте: Хранить приватные ключи сертификатов в защищенном месте, например, на аппаратном токене или в HSM.
• Защита доступа к сертификатам паролем: Защищать доступ к сертификатам паролем.
• Регулярная ротация сертификатов: Регулярно менять сертификаты для снижения риска компрометации.
• Использовать OCSP или CRL для проверки статуса сертификата: Использовать Online Certificate Status Protocol (OCSP) или Certificate Revocation List (CRL) для проверки статуса сертификатов и выявления отозванных сертификатов.

8. Мониторинг и аудит:

• Мониторинг попыток входа в систему: Мониторить попытки входа в систему и регистрировать все неудачные попытки.
• Обнаружение подозрительной активности: Использовать системы обнаружения вторжений (IDS) для выявления подозрительной активности, связанной с аутентификацией.
• Аудит журналов: Регулярно анализировать журналы для выявления нарушений безопасности.