Является ли эта схема аутентификации с использованием JWT безопасной?

Содержание

Вопрос или проблема
Ответ или решение
Анализ системы аутентификации на основе JWT
Введение
Основные компоненты системы
Преимущества предложенной схемы
Безопасность системы
Вывод

Вопрос или проблема

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

=== Страница входа ===
Проверка учетных данных => Сервер выдает JWT => Хранится в куки

JWT содержит:
exp: таймстамп
uid: UserID
HMAC-SHA512 подпись

Redis хранит:
Ключ: UserID
Значение: SecretKey (вставляется только если не существует)

=== Аутентификация запросов ===
JWT декодирован
$uid = UserID

Redis получает:
Значение: SecretKey из
Ключа: $uid

Проверка HMAC JWT с использованием SecretKey
если проверено
если exp не истек

ВСЁ ОК

Так зачем вообще использовать JWT, когда это на самом деле схема с состоянием, а не без состояния?

Проверка выполняет только один запрос к Redis, нет необходимости делать еще один для получения UserID
Нет необходимости хранить SessionID для каждой сессии, Redis хранит только одну запись для неограниченного количества сессий данного пользователя.
Нет необходимости поддерживать истекшие сессии в Redis и удалять их.
Все токены одного пользователя могут быть отозваны в любое время путем изменения SecretKey

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

В целом выглядит неплохо. Однако стоит подумать о нескольких вопросах

UserID не зашифрован. Если запрос не проходит по TLS, это утечка этой информации для MITM. Может быть, стоит его зашифровать.
После выхода пользователя из системы, что не дает возможности использовать JWT, предположим, что он не истек?

Ответ или решение

Анализ системы аутентификации на основе JWT

Введение

Система аутентификации, описанная в вашем вопросе, использует JSON Web Tokens (JWT) для идентификации пользователей при взаимодействии с веб-приложением. Хотя подход имеет свои достоинства, важно рассмотреть его безопасность и функциональность, особенно в контексте использования токенов и хранения данных.

Основные компоненты системы

Выпуск токенов
- При проверке учетных данных сервер генерирует JWT, который включает:
  - exp: временная метка истечения
  - uid: идентификатор пользователя
  - HMAC-SHA512 подпись
Хранение секретов в Redis
- Секретный ключ для подписи токенов хранится в Redis под ключом UserID.
Аутентификация запросов
- При получении запроса с JWT сервер декодирует его, получает uid, затем извлекает соответствующий секретный ключ из Redis и выполняет проверку подписи и истечения токена.

Преимущества предложенной схемы

Единичный запрос к Redis: Доступ к секретному ключу осуществляется за один запрос, что повышает производительность.
Отсутствие необходимости в хранении SessionID: Это упрощает управление сессиями и снижает накладные расходы на их обработку.
Ревокация токенов: Смена секретного ключа позволяет сразу аннулировать все активные токены для данного пользователя.

Безопасность системы

Несмотря на перечисленные преимущества, схема имеет существенные недостатки и риски, которые важно учитывать:

Передача данных без шифрования:
- Если запросы не защищены с помощью TLS (HTTPS), идентификатор пользователя (uid) становится уязвимым для атак типа "человек посередине" (MITM). Рекомендуется шифровать данные в токене, чтобы предотвратить утечку информации.
Управление сессиями:
- После выхода пользователя JWT может оставаться активным до истечения срока действия (exp). Это создает риск несанкционированного доступа, если токен был украден. Одним из решений может быть добавление механизма черного списка (blacklist) для отозванных токенов.
Отсутствие дополнительных уровней защиты:
- Чем меньше данных в JWT, тем лучше. Однако, если в токене содержится идентификатор пользователя, следует рассмотреть возможность добавления других мер безопасности, таких как использование Claims для ограничения доступа к определенным ресурсам.

Вывод

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

Если вы хотите обеспечить надежную защиту вашей системы, следует рассмотреть:

Использование HTTPS для шифрования трафика.
Введение механизма черного списка для отзыва активных токенов.
Подумать о криптографической защите идентификаторов пользователя.

Эти рекомендации помогут сделать вашу аутентификационную систему более безопасной и надежной.