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

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

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

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

на самом деле, это относится ко всем проверка подлинности на основе маркеров.

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

94
access-token authentication jwt

2 ответов

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

во-первых, JWTs обычно не зашифровать. Хотя есть способ шифрования JWTs (см.:JWEs), это не очень распространено на практике по многим причинам.

далее, любая форма аутентификации (с использованием JWTs или нет), подвержена атакам MitM (man-in-the-middle) атаки. Эти атаки происходят, когда злоумышленник может просматривать сетевой трафик при выполнении запросов через интернет. Это то, что может видеть ваш провайдер, АНБ и т. д.

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

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

теперь, вот где протоколы приходят.

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

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

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

способ работы OAuth2 заключается в том, что он был разработан для предоставления клиентам временных токенов (например, JWTs!) для аутентификации только в течение короткого периода времени!

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

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

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

надеюсь, это поможет ^^

164

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

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

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

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

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