Как защитить пользователя от кражи jwt токена в laravel?

Question

[frontendo]

В ларе есть реализация jwt-auth. В ней предусмотрены срок истечения токена и его обновление jwt.refresh. Но как быть, если токен был похищен злоумышленником и до истечения срока или после (при неакивности пользователя) обменян на новый. Таким образом пользователь уже не может обновить свой старый токен (так как его обновил злоумышленник) и будет заново получать токен путем ввода логина и пароля. А вор будет беспрепятственно пользоваться аккаунтом, периодически обновляя токен. Как решить такую проблему? или может она уже решена?

Answer 1

[dskozin]

Здравствуйте!
Вопрос реальный (т.е. вы с такой ситуацией столкнулись) или гипотетический?

Насколько я понимаю процесс авторизации происходит примерно следующим образом:
1. Пользователь вводит логин и пароль - ему выдается токен1
2. Проходит какое-то время токен1 устаревает, и в течении некоторого времени после этого сервер позволяет сделать рефреш, т.е. по токену1 получить токен2, при этом никакие функции кроме рефреша становятся недоступны.
3. Пользователь пользуется токеном2

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

Но! Реальный пользователь пройдя процедуру авторизации получит токен3, который (если) злоумышленник не знает, а следовательно и не сможет получить рефреш.

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

Comments

[frontendo]

да, вы все правильно поняли. меня и волнует этот промежуток до повторной аутентификации реального юзера. Так в этом модуле jwt-auth, который на гитхабе имеет 1500 звезд даже протухание похищенного токена не предусмотрено после повторного ввода логина и пароля реальным пользователем

[dskozin]

Мне казалось что этот плагин весьма гибкий. Возможно, что отсутвие протухания похищенного токена обусловлено такими кейсами, когда пользователь заходит в приложение с разных устройств, и следовательно имеет несколько актуальных (и протухших) токенов, а система просто не разбирает к какому устройству принадлежит токен.
Т.е. если добавить к таблице, в которой хранятся токены колонку уникального ИД устройства, и позволить для устройства иметь только один валидный токен (который при протухании обновляется) система начнет работать с защитой от кражи..

Предлагаю просто форкнуть jwt-auth. Мне понравилось как автор внутри его написал. Там очень красиво.

[frontendo]

dskozin: что мешает злоумышленнику отправить запрос вместе с ид устройства? Предположим, запрос со всеми параметрами был извлечен прямо из браузера) Это нам ничего не даст