Авторизация JWT и утечки токенов

Question

Мне нужна помощь в понимании безопасности токенов JWT, используемых для входа в систему. В частности, как он предотвращает атаку злоумышленника, который может видеть пакеты пользователя? Я понимаю, что, зашифрованный или нет, если злоумышленник получит доступ к токену, он сможет скопировать токен и использовать его для входа в систему и доступа к защищенному ресурсу. Я читал, что именно поэтому срок жизни токена должен быть коротким. Но насколько это действительно помогает? Чтобы получить ресурс, не нужно много времени. И если злоумышленник смог украсть токен один раз, не могут ли они сделать это снова после обновления sh?

Нет ли способа проверить, что токен, отправленный клиентом, отправляется из того же клиент, которому вы его отправили? Или я упустил суть?

Answer 1

Чтобы добавить к отличному ответу Матуса:

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

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

В вашем случае я, возможно, поступил бы аналогичным образом:

• Какие есть альтернативы?
• В каких областях существуют проблемы с токенами на предъявителя?
• Есть ли альтернативы лучше в этих областях?

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

Answer 2

как это предотвратить атаку со стороны злоумышленника, который может видеть пакеты пользователя?

Тот факт, что вы видите чьи-то пакеты, не означает, что вы можете видеть их содержимое. HTTPS шифрует трафик c, поэтому, даже если кому-то удастся перехватить ваш трафик c, он не сможет извлечь из него JWT. Каждый веб-сайт, использующий аутентификацию, должен работать только через HTTPS. Если кто-то сможет выполнить атаку «злоумышленник посередине», то это уже другая история.

они смогут скопировать токен и использовать его для входа в систему и доступа к защищенному ресурсу.

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

И если злоумышленник может украсть токен один раз, может t они делают это снова после обновления sh?

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

Нет ли способа проверить, что токен, отправленный клиентом, отправляется тем же клиентом, которому вы его отправили?

Если злоумышленник успешно выполняет атаку «человек посередине», они могут подделать любую информацию, которую вы могли бы использовать для проверки клиента, поэтому ответ будет отрицательным, 100% надежного способа проверки клиента не существует.

Самая большая проблема, которую я вижу с JWT, - это не сами JWT, а то, как они обрабатываются некоторыми людьми (хранятся в незашифрованном локальном хранилище браузера, содержащем PII, без HTTPS, без двухфакторной аутентификации, где это необходимо, и т. Д. c ...)