Что делать, если JWT украден?

Question

Я пытаюсь реализовать аутентификацию без состояния с помощью JWT для моих API RESTful.

AFAIK, JWT - это в основном зашифрованная строка, переданная как HTTP-заголовки во время вызова REST.

Но что, если есть прослушиватель, который видит запрос, и крадет токен? Тогда он сможет подделать запрос с моей личностью?

На самом деле эта проблема относится ко всем аутентификации на основе токенов.

Как предотвратить это? Безопасный канал, такой как HTTPS?

Answer 1

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

Прежде всего, JWTs обычно NOT зашифрован. Хотя существует способ шифрования JWT (см.: JWEs), это не очень распространено на практике по многим причинам.

Далее, любая форма аутентификации (с использованием JWT или нет) может подвергаться атакам MitM-атак (man-in-the-middle). Эти атаки происходят, когда злоумышленник может ПРОСМОТРЕТЬ ваш сетевой трафик, когда вы делаете запросы через Интернет. Это то, что может видеть ваш интернет-провайдер, NSA и т. Д.

Это то, что SSL помогает предотвратить: путем шифрования трафика NETWORK с вашего компьютера -> на каком-либо сервере при аутентификации, сторонняя организация, контролирующая сетевой трафик, может НЕ увидите ваши жетоны, пароли или что-то в этом роде, если они не смогут получить копию секретного ключа SSL сервера (маловероятно). Именно по этой причине SSL является ОБЯЗАТЕЛЬНЫМ для всех форм аутентификации.

Допустим, однако, что кто-то сможет использовать свой SSL и способен просматривать фишку: ответ на ваш вопрос в том, что ДА, злоумышленник будет иметь возможность использовать этот маркер, чтобы выдавать себя за вас и делать запросы на ваш сервер.

Теперь, это где протоколы бывают.

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

ОДНАКО, сами JWT не имеют ничего общего с «безопасностью». Для всех целей и целей JWT более или менее совпадают с ключами API: просто случайные строки, которые вы используете для аутентификации на каком-то сервере где-то.

Что делает ваш вопрос более интересным, используется протокол (скорее всего, OAuth2).

Способ OAuth2 работает, заключается в том, что он был предназначен для предоставления клиентам TEMPORARY токенов (например, JWT!) Для аутентификации только для КОРОТКОГО ПЕРИОДА ТОЛЬКО!

Идея состоит в том, что если ваш токен украден, злоумышленник может использовать его только в течение короткого периода времени.

С помощью OAuth2 вы должны повторно идентифицировать себя с сервером так часто, указав свои имя пользователя/пароль или учетные данные API, а затем получая токен обратно в обмен.

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

Надеется, что это помогает ^^

Answer 2

Я знаю, что это старый вопрос, но я думаю, что может упасть мой $ 0,50 здесь, вероятно, кто-то может улучшить или предоставить аргумент, чтобы полностью отклонить мой подход. Я использую JWT в RESTful API через HTTPS (ofc).

Для этого вам всегда нужно выдавать недолговечные токены (в зависимости от большинства случаев, в моем приложении я фактически устанавливаю заявку exp на 30 минут и ttl до 3 дней, так что вы можете обновить этот токен до тех пор, как его ttl остается в силе, и маркер не был черный список)

для authentication service, чтобы аннулируют жетоны, мне нравится использовать слой кэша в памяти (Redis в моем случае) как JWT blacklist/ban-list спереди, в зависимости от некоторых критериев: (Я знаю, что это ломает RESTful ph ilosophy, но сохраненные документы действительно недолговечны, так как я в черный список за оставшееся время к проживанию - ttl претендуя)

Примечание: черный список токенов не может быть автоматически обновляется

• Если user.password или user.email был обновлен (требуется подтверждение пароля), служба auth возвращает обновленный токен и отменяет (черный список) предыдущий, поэтому, если ваш клиент обнаруживает, что пользовательский идентификатор был каким-то образом взломан, вы можете попросить пользователя изменить его пароль. Если вы не хотите использовать черный список для этого, вы можете (но я не рекомендую вам) утвердить заявку iat (выдается на) в отношении user.updated_at (если jwt.iat < user.updated_at, то JWT недействителен).
• Пользователь сознательно вышел из системы.

Наконец, вы точно проверяете токен, как и все.

Примечание 2: вместо того, чтобы использовать сам маркер (который очень долго) в качестве ключа кэша-, я предлагаю генераторный и используя UUID маркера для jti претензии. Что хорошо, и я думаю (не уверен, так как это только пришло мне в голову), вы можете использовать тот же UUID, что и токен CSRF, возвращая с ним файл cookie secure/non-http-only и правильно используя заголовок X-XSRF-TOKEN с помощью js. Таким образом, вы избегаете вычислительной работы по созданию еще одного токена для проверок CSRF.