JWT. Часть 2. Проблемы

[@bakhtiyardabylov648]

Чувак, ты просто сверхчеловек. После первого видео о JWT и сессиях я сразу же подписался, после второго я запомнил твой канал. Теперь буду частенько заходить и ставить лайки. Главное не бросай свое творчество, у тебя хорошая осведомленность в данном деле, и, что еще важнее для ютубера, у тебя дар преподавателя. Удачи тебе и большое спасибо

[@oerbyy]

+100500! Отличная подача! Спасибо Ninja!

[@doter-fe8li]

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

[@romanhaida5837]

Когда ожидать следующие части??

[@МаксимПучко-ь9э]

Уже есть все части, можно смотреть

[@tehFSMonster]

Не совсем понял объяснения. Что нам даёт хранение отозванных токенов? Почему недостаточно просто заставлять пользователей перелогиниться, если выяснилась компрометация учётной записи после refresh-token?

[@SmiteVils]

Продолжай записывать, очень интересно!

[@ivangolubev7308]

3:01 Т.е. резюмируя - у нас есть токен, который не хранит в себе информацию о том, валидный он или нет, и у нас есть знание, что он скомпрометирован - как отозвать его? Нужно вводить доп. сущность, доп. информацию - например хранить в БД все валидные токены, или хранить в БД вообще все токены, но у невалидных будет поле isValid=false, то есть нам надо вводить централизованное хранилище, а это ни что иное, как сессия. Я прав?

[@musoverda5500]

а где обещанные следущие видосики с практикой? )

[@StoneWeaver_RU]

А продолжение-то где? Как бы уже больше полугода прошло...

[@jsonslim]

Спасибо, как раз для своего проекта хотел использовать JWT, теперь буду делать сессию

[@Sergey111111]

3:09 Кредо программиста - изобретение велосипедов!

[@andrewzabara68]

Илья мог бы ты рассказать в следующих видео о MVVM его преимуществах и недостатках

[@Диваныч-ъ7ц]

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

[@----1281]

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

[@MykolaParamonov]

Меня это тоже озадачило(

[@ivangolubev7308]

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

[@SweettyDavid]

Very nice lessons

[@sleepstream9433]

6 лет занимаюсь бэкэндом с микросервисами, jwt с lifetime 5 минут, как его можно угнать?? Refresh token при угоне инвалидирует токен юзера, юзер перелогинится, инвалидируется токен угонщика и он больше не может ничего делать. В чем я не прав?

[@JavaScriptNinja]

Для этого рефреш токен будет уже не jwt

[@SweettyDavid]

Great job

[@vitaliidrapaliuk5652]

Спасибо)

[@brud90]

Фактически, можно и кукис с айди сессии угнать, но у сессий нет рефреша, а против csrf есть csrf-токен, т.е. если сравнивать голые реализации, то по безопасности особой разницы нет, верно я понял?

[@JavaScriptNinja]

Anton Iliyn сессии в среднем по больнице безопаснее

[@brud90]

Javascript.Ninja ну если чувак угонит куку с сессией, то это надолго + в jwt мы узнаем о компрометации по неверному рефреш токену

[@ivsergey5150]

круто! ждем еще видосов

[@volodymyrkorniienko8670]

так а где 3-я часть?

[@МаксимПучко-ь9э]

Если ты еще не смотрел третью, то могу сказать, что уже вышла 4-я часть

[@kasarch]

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

[@alexxis246]

Нет. С точки зрения пользователя - разлог раздражает и тратит драгоценные (для некоторых пользователей) минуты. Еще может оказаться так, что у пользователя, на момент разлогина, нет возможности авторизоваться (забыл блокнот с паролями).

[@maratmkhitaryan9723]

@@alexxis246 Если пользователя раздражает разлогин 1 раз в год из-за утечки то ему стоит подлечить нервы. Если нету пароля то пусть восстановит через форму восстановления пароля.

[@yevhenbadorov7961]

@@maratmkhitaryan9723 но ведь нет никакой гарантии, что будет 1 утечка в год

[@СергейКиселев-ю6щ]

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

[@nikolay7081]

@@maratmkhitaryan9723 достаточно представить, что пользователь заполнял какую-нибудь большую форму 15 минут и тут при сабмите его разлогинивает и данные придется заполнять с самого начала. правда весело?)

[@ivansidorov5]

А мы не можем использовать сессии в AJAX?

[@АнтонВасильев-т2я]

Отлично

[@auditusich]

А для нативок можно придумать суперсекретный ключ который доступен в клиентском приложении и на сервере. Он никогда не передается по сети. Рефреш токен при отправке клиенту шифруется этим ключом. Если хакер угонит рефреш, то ему придется еще и копаться в байткоде что бы найти суперсекретный ключ. Правда это добавит головной боли как хакеру так разработчику

[@MK-we4dl]

Не пойму что-то. Как можно сделать кросс-сайт атаку если кука подписана ключем на сервере о котором знает только сервер? Ну залогинется хацкер на своем сайте, ну получит свою куку, а подпись он как сделает? И о каких нафиг хакерах идет речь когда у юзеров пароли на мониках висят. Или вообще шедевральная возможность сохранить пароль в браузере, устроился в сервис на работу и сливай пароли с каждого устройства.

[@sleepstream9433]

кука не шифруется никаким образом, поэтому и получается получить все токены со всеми потрахами, но от csrf куку можно защитить политиками браузера.

[@gen7891]

Проблемы в том что сессию надо создавать на сессии. И jwt не надежный. Можно резюмировать так.

[@ДилэймНиколсон]

Категорически не согласен с тем, что если в токене хранить только ID пользователя, а за остальными данными обращаться в БД, то это выходят те же сессии. В случае с сессиями мы получаем Session ID, дальше из БД/файлов/ещё-чего-нибудь получаем связанного с ней пользователя. В случае же с JWT у нас отпадает лишнее звено в виде проверки сессии вне сервера. В то же время хранить абсолютно все необходимые данные о пользователе в JWT просто невозможно. Как-минимум потому-что если у вас появляется какое-то новое поле, то придётся заставлять всех пользователей перелогиниваться, что бы приложение корректно работало.

[@JavaScriptNinja]

Как вы проверите сценарий отозванного токена без обращения в БД?

[@ДилэймНиколсон]

"Буду хранить в токене только ID, а всё остальное на сервере в хранилище" - вы имели в виду id сессии или id пользователя?

[@JavaScriptNinja]

А это неважно и деталь реализации. Что так что так вам надо получить связанного пользователя по какому-то ключу. Будет ли это session id или user id - совершенно ничего не меняет

[@ДилэймНиколсон]

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

[@JavaScriptNinja]

Я ж и не против :)

[@АсланКосшанов]

А этот хакер случайно не Профессор из сериала Бумажный дом?

[@eugenesternin6039]

скомпрометирован, не скомпромеНтирован

[@lollolich2399]

А что если мы будем хранить в рефреш токене ip адрес и девайс, с которого произошёл логин, и шифровать этот токен. Далее представим злоумышленник украл рефреш токен и пытается получить новый рефреш токен. Об cодержание токена, то есть об ip адресе и девайсе ему ничего не известно в силу того, что токен - это какая-та зашифрованная строка. Мы получаем от него украденный рефреш токен, дешифруем его, сверяем айпи адрес и девайс запроса с соответствующими значениями в токене, если проверка не прошла, то отклоняем запрос, иначе, то есть запрос на новый рефреш токен делает исходный юзер, что и получил изначальный рефреш токен, тогда выдаём новый рефреш токен. Какие подводные камни у такой схемы?

[@blackobemamatters4418]

Тогда юзер не сможет логинитса на наш сайт с другого устройства(например с телефона).

[@ломастер]

🤯

[@sivkaburka1062]

Досмотрел до конца

[@МаксимСеливанов-ь6н]

Дружище, "скомпромеНтирован" не есть гуд) Скомпрометирован же! Успехов и роста)

[@SergeiSokolov22]

JWT произносится "jot" /dʒɒt/

[@fedorkuruts]

Меня иногда пугают фоны. Вроде умный дядька. Рассказывает хорошо, а живёт хрен знает где. Какое то кресло убитое, шкаф. Вот и учись на программиста ...

[@JavaScriptNinja]

Вы на новые фоны посмотрите :)) Это видео у родителей записывалось :))

[@fedorkuruts]

@@JavaScriptNinja Купи родителям кресло нормальное)))

[@JavaScriptNinja]

@@fedorkuruts Сейчас иные приоритеты

[@XenonIPC]

автор, главная проблема только одна: Вы плохо понимаете механизмы работы и АБСОЛЮТНО некорректные делаете выводы. Здравые рассуждения начинаются только на 6й минуте, когда задаете вопрос "Где хранить токены?" (и что в local storage этого делать нельзя). По сути это главная и пожалуй единственная проблема jwt. Я бы мог расписать каждый пункт и показать ошибочность суждений и выводов, но это долго. Надеюсь что за эти 3 года автор вырос в своих познаниях, но тогда странно почему это видео не скорректировано и не перезалито...

[@JavaScriptNinja]

Не вырос :) Даже деградировал и в ряде сценариев одобряю хранение токенов в localstorage :)

[@tehFSMonster]

Проблема токенов в том, что их можно угнать. И уже только одно это их компрометирует.

[@DmitryPolovka]

Если вы собрались комментировать что тут неправильная информация, тогда уже пишите о том как сделать лучше

[@vsezanyato]

Думаю всем была бы полезна информация о том, что в этом видео ошибочно. Хотя бы вкратце ..

[@sleepstream9433]

@@tehFSMonster токены в куках угнать нельзя, если вы нормально изучите вопрос

[@dmitryprokofyev1473]

Красивый цвет помады

[@Antonio-fm1sq]

Спасибо!