12:40 в итоге получаем особый вид вредительства - "разлогинивание пользователей каждую минуту" =) 14:30 ошибка. если истек refresh token, то это разлогинивание без иных вариантов. Для того, чтоб избежать разлогинивания, за определенный период времени перед истечением refresh token необходимо отправить запрос на его обновление. Например, если сам токен живет месяц, то за неделю до его истечения обновляем refresh token
Время жизни токена устанавливается на стороне сервера кодером, ну и конечно устанавливаются те числа которые нужны по логике кодера )) Спасибо за видео!
Про токены: если refresh токен получил злоумышленник, но он может сам создать токен. Поэтому сторонние плагины при получении доступа к access token, могут получить доступ и к refresh токену. Путь решения проблемы автор ролика упоминул, - разлогиниться.
Сессия и токен это не виды авторизации. Сессия это единица учета пользователя в системе. А токен это расширенный формат этой единицы учёта, в нём есть заявки пользователя. В обоих случаях, сама авторизация происходит потом, на основе этой единицы учёта. Те же jwt токены так же нуждаются в сессиях и их управлении. Черный список не решает проблемы токенов, потому как кроме всего прочего необходимо вести учёт того сколько раз пользователь зашел под одним и тем же аккаунтом, иначе шаренный аккаунт будет юзаться всеми кому не лень. jwt был придуман для того чтобы разгрузить процесс авторизации(проверки пермишенов), а не для того чтобы заменить сессии.
На практике можно болт положить на устройство jwt токена за 3-4 года работая с микросервисами где токены активно юзаются ни разу об этом не думал так мельком гуглил шо оно такое вначале и благополучно пошел дальше, но на каждом собесе это цепляют.. - спрашивается вот зачем каждому разработчику знать эту подноготную?? - если ты не работаешь над auth модулем или чем то где вот именно эти знания реально нужны - как впрочем и др топики из этой же серии: сборка мусора - мне глубоко до 3,14 как оно там собирает мусор - сборку мусора для того и придумали что б я об этом не парился. 0,1% задач где это важно в остальных случаях это только нагружает мозг и замедляет процесс написания кода - ведь мозгу приходится процессить мне создать как обычно класс или всё-таки структуру.. - я так понял что мир полон задротов которые хотят всех под свою гребенку расчесать когда спрашиваешь интервьювера а зачем мне под ваши реквайрменты знать то что ты спрашиваещь - в 9 из 10 случаев человек меньжуется ну типа я общий уровень проверяю..
Да, некоторые спрашивают про энциклопедические данные, которых за несколько лет возможно ни разу не приходилось использовать. Не уж то так прикольно работать с задротами в команде. Ведь тех детали всегда можно подсмотреть в нужный момент
Уважаемый друг! Спасибо за видиеоурок. Скажи пожалуйста как можно решить следующую аутентификацию когда появляются на телефоне два разные токена при авторизации в виде семизначными цифрами и второе шестизначными цифрами на короткое время и просят нажать кнопку отправить и исчезает. А на следующем этапе появляется один токен с другими шестизначными цифрами и требует записать второго токена семизначного цифра. Как можно решить такую аутентификацию? Помоги если сможешь.
Какой в едренефене доступ к обновляемому токену? Обновляемый токен является одноразовым и если злоумышленик его получает, то у тебя получается проблема, так как ты получишь уведомление, о том что твой токен неверен"протух".
Под обновляемым токеном имеется ввиду access token? Или refresh token? Access token живёт, как правило, около 5 минут и одноразовым не является. Кроме того, никто не запрещает пользователю логиниться с нескольких устройств и в случае ошибки обновления access token'а - пользователя просто разлогинит и он зайдёт заново и получит новую пару access и refresh, что вообще никак не повлияет на ситуацию, когда у злоумышленника оказался refresh token, потому что он может без особых проблем сидеть и обновлять его, выписывая новую пару токенов. Для решения таких проблем токены обычно выносят в куки, защищённые от вмешательства со стороны JS, чтобы их украсть было не такой простой задачей.
@@dobryakov , хэштруется, а не шифруется. Т.е. это своего рода контрольная сумма данных (в данном случае заголовка и тела токена), только криптографически стойкая. Эта контрольная сумма потом шифруется на ключе подписи сервера авторизации (т.к. сервер данных находится в цепочке доверия с сервером авторизации, то у сервера данных есть ключ проверки подписи сервера авторизации). На стороне сервера данных происходит расшифрование подписи на ключе проверки подписи, получаем хэш, который сравниваем с результатом хэширования заголовка и тела токена. При совпадении этих хэшей и получаем подтверждение подлинности и неизменности данных в токене. Если уж рассказываете про безопасность и, упаси Бог, употребляете слова: ключ, шифрование, подпись, хеширование, - то советую разобраться в этом поглубже, чтобы подобные вопросы в комментариях не возникали.
Разумеется, я имел ввиду токен, по которому происходит авторизация. И чаще всего, этот самый токен действительно хранится в куках. Понятно, что сама по себе сессия хранится в базе данных и привязывается к определённому пользователю, но гуляя между фронтом и бэком -- она находится в куках (в подавляющем большинстве случаев)
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
Мне здорово помогла эта инфа! И прикрепленная тоже.
спасибо мужик, удач во всем (сообщение более пяти слов для алгоритма ютьюба))
Спасибо!
12:40 в итоге получаем особый вид вредительства - "разлогинивание пользователей каждую минуту" =)
14:30 ошибка. если истек refresh token, то это разлогинивание без иных вариантов. Для того, чтоб избежать разлогинивания, за определенный период времени перед истечением refresh token необходимо отправить запрос на его обновление. Например, если сам токен живет месяц, то за неделю до его истечения обновляем refresh token
Спасибо. Кратко, ёмко, понятно))
Все четко и по делу. Хорошо расписано и понятно. Лайк и подписка
Время жизни токена устанавливается на стороне сервера кодером, ну и конечно устанавливаются те числа которые нужны по логике кодера ))
Спасибо за видео!
Нет ничего невозможного, все зависит от времени, мастерства и желания
Про токены: если refresh токен получил злоумышленник, но он может сам создать токен. Поэтому сторонние плагины при получении доступа к access token, могут получить доступ и к refresh токену.
Путь решения проблемы автор ролика упоминул, - разлогиниться.
Благодарю
Большое спасибо за информацию
спасибо за видео)
Видео классное, но jwt токен можно подменить, если ключ шифрования не был достаточно надежен, можно забрутфорсить
Очень круто
Спасибо!
Сессия и токен это не виды авторизации. Сессия это единица учета пользователя в системе. А токен это расширенный формат этой единицы учёта, в нём есть заявки пользователя. В обоих случаях, сама авторизация происходит потом, на основе этой единицы учёта. Те же jwt токены так же нуждаются в сессиях и их управлении. Черный список не решает проблемы токенов, потому как кроме всего прочего необходимо вести учёт того сколько раз пользователь зашел под одним и тем же аккаунтом, иначе шаренный аккаунт будет юзаться всеми кому не лень. jwt был придуман для того чтобы разгрузить процесс авторизации(проверки пермишенов), а не для того чтобы заменить сессии.
На практике можно болт положить на устройство jwt токена за 3-4 года работая с микросервисами где токены активно юзаются ни разу об этом не думал так мельком гуглил шо оно такое вначале и благополучно пошел дальше, но на каждом собесе это цепляют.. - спрашивается вот зачем каждому разработчику знать эту подноготную?? - если ты не работаешь над auth модулем или чем то где вот именно эти знания реально нужны - как впрочем и др топики из этой же серии: сборка мусора - мне глубоко до 3,14 как оно там собирает мусор - сборку мусора для того и придумали что б я об этом не парился. 0,1% задач где это важно в остальных случаях это только нагружает мозг и замедляет процесс написания кода - ведь мозгу приходится процессить мне создать как обычно класс или всё-таки структуру.. - я так понял что мир полон задротов которые хотят всех под свою гребенку расчесать когда спрашиваешь интервьювера а зачем мне под ваши реквайрменты знать то что ты спрашиваещь - в 9 из 10 случаев человек меньжуется ну типа я общий уровень проверяю..
Да, некоторые спрашивают про энциклопедические данные, которых за несколько лет возможно ни разу не приходилось использовать. Не уж то так прикольно работать с задротами в команде. Ведь тех детали всегда можно подсмотреть в нужный момент
за 10 процентов сложной работы платят 70 процентов денег в IT
Уважаемый друг! Спасибо за видиеоурок. Скажи пожалуйста как можно решить следующую аутентификацию когда появляются на телефоне два разные токена при авторизации в виде семизначными цифрами и второе шестизначными цифрами на короткое время и просят нажать кнопку отправить и исчезает. А на следующем этапе появляется один токен с другими шестизначными цифрами и требует записать второго токена семизначного цифра. Как можно решить такую аутентификацию? Помоги если сможешь.
Какой в едренефене доступ к обновляемому токену? Обновляемый токен является одноразовым и если злоумышленик его получает, то у тебя получается проблема, так как ты получишь уведомление, о том что твой токен неверен"протух".
Под обновляемым токеном имеется ввиду access token? Или refresh token?
Access token живёт, как правило, около 5 минут и одноразовым не является. Кроме того, никто не запрещает пользователю логиниться с нескольких устройств и в случае ошибки обновления access token'а - пользователя просто разлогинит и он зайдёт заново и получит новую пару access и refresh, что вообще никак не повлияет на ситуацию, когда у злоумышленника оказался refresh token, потому что он может без особых проблем сидеть и обновлять его, выписывая новую пару токенов.
Для решения таких проблем токены обычно выносят в куки, защищённые от вмешательства со стороны JS, чтобы их украсть было не такой простой задачей.
Спасибо за ролик. Но всё-таки как на сервере "расшифровывается" содержимое jwt, если sha256 - необратимое шифрование?
Всё не совсем так. В sha-256 шифруется только часть, которая является подписью сервера, остальное содержимое токена просто закодировано в base64.
@@dobryakov , хэштруется, а не шифруется. Т.е. это своего рода контрольная сумма данных (в данном случае заголовка и тела токена), только криптографически стойкая. Эта контрольная сумма потом шифруется на ключе подписи сервера авторизации (т.к. сервер данных находится в цепочке доверия с сервером авторизации, то у сервера данных есть ключ проверки подписи сервера авторизации). На стороне сервера данных происходит расшифрование подписи на ключе проверки подписи, получаем хэш, который сравниваем с результатом хэширования заголовка и тела токена. При совпадении этих хэшей и получаем подтверждение подлинности и неизменности данных в токене. Если уж рассказываете про безопасность и, упаси Бог, употребляете слова: ключ, шифрование, подпись, хеширование, - то советую разобраться в этом поглубже, чтобы подобные вопросы в комментариях не возникали.
ничего непонятно =(
не стуртурированно. С самого начала начал вскользь бегать по разным аспектам. Крч в башке каша одна после видоса
После 9 минут просмотра ни слова про oayth и собственно jwt. Заголовок кликбейтный, дизлайк
есть же таймкоды :)
Нести откровенную чушь важным тоном и учить людей тому, в чем сам не разбираешься - это особый скилл.
«Сессия хранится в куках» - восхитительно
Разумеется, я имел ввиду токен, по которому происходит авторизация. И чаще всего, этот самый токен действительно хранится в куках. Понятно, что сама по себе сессия хранится в базе данных и привязывается к определённому пользователю, но гуляя между фронтом и бэком -- она находится в куках (в подавляющем большинстве случаев)
Топ видео
Недавно на сайте вконтакте уаидел в payload мои данные в нешифрованном виде ,как такое возможно?
Спасибо за ролик. Но всё-таки как на сервере "расшифровывается" содержимое jwt, если sha256 - необратимое шифрование?
В sha256 хэшируется только подпись токена. Сам токен просто закодирован в base64.