ТЫ ДЕЛАЕШЬ ЭТО НЕПРАВИЛЬНО! JWT VS SESSION ДЛЯ АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЯ
HTML-код
- Опубликовано: 6 апр 2022
- ТЫ ДЕЛАЕШЬ ЭТО НЕПРАВИЛЬНО! JWT VS SESSION ДЛЯ АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЯ
Python on Papyrus RU.
Мои курсы на UDEMY: www.udemy.com/user/andrey-iva...
Пожертвования: www.donationalerts.com/r/pyth...
Github: github.com/knucklesuganda
Telegram канал: t.me/pypapyrus_ru
Другие Видео по Python: • Python, Питон
Канал на английском языке: / @pythononpapyrus
Поставьте лайк и подпишитесь!
#Python #Питон #программирование #programming
1) В большинстве Python веб-фреймворков все данные сессии пользователя по-умолчанию хранятся в куках. Не только session id, но и полезная нагрузка (всего, где-то до 4 килобайт данных). Хотя это ни разу не JWT.
2) Чтобы полезную нагрузку нельзя была прочитать вне сервера, пакет aiohttp-session (вместе с пакетом cryptography) может использовать шифрование куки перед отправкой пользователя и расшифровку при получении куки от пользователя (используется схема шифрование Fernet на основе AES-128).
3) JWT обычно не шифруется, но подписывается. Цифровая подпись на основе хеш-функции и секрета -- это не шифрование данных.
В общем, дизлайк.
Вы что jwt стандарт для банков как минимум)
У jwt есть еще преимущества по аутентификации пользователе в нескольких системах. Пример: зарегистрировался в gmail и работаешь в инстаграм.
@@valk9819, я утверждал обратное?
@@airat5551, не совсем. Это если JWT хранится не в куках. JWT -- это стандартный формат токена, а не способ хранения. Вы можете изобрести свой аналог JWT и хранить его хоть в куках, хоть в локальном хранилище.
Какие есть способы безопасной регистрации аккаунта и входа? (Я сейчас разрабатываю http web сервер на golang без фреймворка). До этого момента я не очень задумывался о безопасной аутентификации и хранил md5(md5(login)+md5(password)) в куки. Но как я понимаю, перехват этого токена приведёт к полному контролю над аккаунтом. Какой вариант аутентификации лучше использовать? И какие видео по этой теме посоветуешь?
Будут видео по OpenID Connect?
14:15 надо менять и отдавать refresh токен во время смены access токена, тогда хакер разлогинит юзера и (возможно) юзер заподозрит неладное и сменит пароль. Ну или всё-таки хранить refresh токен, ip, устройство и сообщать пользователю, что он залогинен с нового ip/устройства, необходимо срочно поменять пароль (но это мы опять вернулись к сессиям).
хорошая тема но похоже что звук возвращается от стен не вовремя:)))
Увидел, что есть много различных алгоритмов защиты сообщения, пришлось разбиратся в глубинах криптографии, спасибо за видео!
Не согласен с последним моментом. Каким образом в JWT можно взломать всех пользователей ? (Получить секрет который хранится на сервере) А так это только одиночные атаки по перехвату. А чтоб сбросить все авторизации по JWT достаточно обновить секрет.
Спасибо за интересный контент :3
В следующем видео покажу что я имел ввиду
А насчет сброса: проблема не в том что нельзя все сразу убрать. Она в основном лежит в идее, что мы не можем убрать токены точечно, так как у нас нет хранилища где они лежат. Хоть так удалять данные никто не будет скорее всего, но все-таки это может быть каким-то преимуществом в сессиях
@@PythononPapyrusRU Ну так можно просто использовать хранилище со списком токенов и все.
Досмотрел до 2:17 и уже 2 замечания. Разочаровываешь((
Интересно, какие?