если иметь правильно оборудованное помещение и аккуратно обращаться с бумажными носителями, то их можно хранить и использовать очень долго и практически без потерь
Есть два важных нюанса: во-первых, «практически». Во-вторых, если для бумаги и подобного достать подходящее помещение очень проблематично, то для сохранения цифрового материала достаточно десяток-другой минут разобраться в матчасти — и профит без всяких «практически».
Алсо, не стоит забывать, что совпадение пиксель-в-пиксель не обязательно означает совпадение байт-в-байт: некоторые картинкохостинги при сохранении качества могут удалять какую-нибудь мета-информацию из картинок.
Алсо [2], я сам иногда не только ищу оригиналы, но и даже пытаюсь рисовать фуллашди-версии мемасиков по требованию внутреннего перфекциониста)
Телефон поймал вайфай и подключился к нему, отключив мобильный интернет. А я набираю этот комментарий. Если в это время меня ВНЕЗАПНО разлогинит из-за всего лишь подключения вайфая — телефон с большой скоростью устремится в сторону пола.
Конечно пусть, только писать про это хабрапосты совсем не обязательно :) У меня тоже есть маленький самопальный язык с самопальной компиляцией (трансляцией?) в самопальный байткод с его самопальной интерпретацией, и всё это трудится на моём маленьком продакшене как простенькая числодробилка-песочница, но бежать писать посты про это я не собираюсь, там всё равно ничего интересного или уникального)
Хотя нет, так тоже не прокатит. Злоумышленник может удалить токен с места утечки (почистить localStorage, например), и тогда в список недействительных токенов добавлять окажется нечего. Придётся всё равно где-то хранить список действительных токенов. В общем, для меня JWT — штука бесполезная)
Вы, может быть, и молодец, только сей пост следовало писать тогда, когда уже появится хотя бы один нормальный рабочий проект на этом языке. А сейчас это всё ещё как-то ни о чём
А почему единомышленников должен заинтересовать ваш «язык», если любой мало-мальски вменяемый программист может написать то же самое или даже лучше за несколько дней? :)
Если честно, я с refresh token'ами работал мало и не до конца их понимаю, не могли бы вы пояснить — если злоумышленник утащит основной токен, то скорее всего где-то рядом он сможет взять и refresh token (если это не mitm), и тогда он просто будет продолжать получать новые токены по этому refresh token'у, что окажется эквивалентно простому долгоживущему токену; я что-то упускаю в описанной схеме или так и есть?
Алсо, я вроде где-то читал, что refresh token отдавать юзеру вообще нельзя, что лишь добавляет путаницы в моём понимании
Окей, я придумал пользу от JWT: список недействительных токенов скорее всего будет намного меньше, чем список действительных, что позволит сэкономить место. Но больше как-то не придумывается (не считая банков, это отдельная история)
Банковские счета это отдельная история, о которой и говорить нужно отдельно, большинство сайтов не являются банками :)
От обычного сайта обычный пользователь будет требовать, чтобы его не разлогинивало. Из-за этого безопасность с короткоживущими токенами СНИЖАЕТСЯ: для постоянного автоматического релогина потребуется хранить пароль (или аналогичную инфу (refresh token?)) в открытом виде где-то рядом с токеном, и его с радостью уведёт злоумышленник вместе с токеном (mitm в эпоху повсеместного https почти нереален, скорее всего будет какой-нибудь RCE/XSS или тупо физический доступ к устройству). Придётся везде менять все пароли, похожие на утёкший. А вот если злоумышленнику попадёт классический долгоживущий токен, то достаточно будет просто удалить его из списка действительных.
JWT выглядит всё более и более бесполезным. Если в итоге всё равно надо логиниться каждые несколько секунд минут (refresh token ведь тоже однажды протухнет? Или я чего-то не понимаю?), то тогда почему бы не тупо посылать пароль (или другую информацию для логина) в каждом запросе, благо HTTPS это безопасно позволяет?)
Или существуют случаи, когда «authorisation sever» и сервер, читающий и проверяющий JWT — не один и тот же сервер? Я с таким ещё ни разу не сталкивался. (Не считая кучки микросервисов, спрятанных за некой единой точкой входа — тогда можно применить схему от fuCtor ниже, и JWT для пользователя опять бесполезен)
Разве что привязка к IP-адресу. Всё остальное при желании можно подделать. Причём касается это не только JWT, но и любых других токенов и кук. Но так как пользователь часто меняет IP и привязка к нему тоже будет неюзерфрендли, в итоге я не знаю ни одной реализации (хоть JWT, хоть не JWT), которая была бы защищена от подобных вещей (ну, помимо короткоживущих токенов, которые так любит vlsinitsyn)
Если отдавать такой токен конечному пользователю, это будет тотальное неюзерфрендли. Перезагрузил комп после обновления винды — всё, заново логиниться? Разве что использовать его по схеме от fuCtor ниже, но тогда для большинства сайтов JWT оказывается бесполезен.
В контексте данного ответа меня всегда интересовал вопрос: как быть, если токеном завладел злоумышленник и его нужно срочно сделать недействительным до истечения его срока годности? Или, другими словами, как реализовывать кнопочку на сайте «Завершить такую-то сессию» / «Завершить все сессии, кроме текущей»? Если сервер никуда не стучится, как он узнает, что токен недействителен?
UPD: ой, тред не читай @ сразу отвечай, ниже то же самое спросили
Во-первых, базар надо не фильтровать, а экранировать. Причём делаться это должно автоматически, чтобы нельзя было забыть заэкранировать в каком-нибудь месте.
Во-вторых, все три пункта ничего не значат. Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json, в котором есть и защита от cross-origin, и не используются сторонние библиотеки, и весь ввод фильтруется/экранируется, только какой толк от всего этого, если там разработчик тупо забыл прописать проверку доступа и любой пользователь, узнав про существование этого API, может изменить или в особо запущенных случаях даже прочитать пароль любого другого пользователя?)
Только пользуетесь то вы продуктом бизнеса, а он делает то что ему выгодно, все что вы ведите в интернете создано не для вас любимого, а для личного обогащения хозяина этого бизнеса(сайта)
Я знаю «Путин каждый день», пять лет уже существует
Есть два важных нюанса: во-первых, «практически». Во-вторых, если для бумаги и подобного достать подходящее помещение очень проблематично, то для сохранения цифрового материала достаточно десяток-другой минут разобраться в матчасти — и профит без всяких «практически».
Алсо, не стоит забывать, что совпадение пиксель-в-пиксель не обязательно означает совпадение байт-в-байт: некоторые картинкохостинги при сохранении качества могут удалять какую-нибудь мета-информацию из картинок.
Алсо [2], я сам иногда не только ищу оригиналы, но и даже пытаюсь рисовать фуллашди-версии мемасиков по требованию внутреннего перфекциониста)
Телефон поймал вайфай и подключился к нему, отключив мобильный интернет. А я набираю этот комментарий. Если в это время меня ВНЕЗАПНО разлогинит из-за всего лишь подключения вайфая — телефон с большой скоростью устремится в сторону пола.
Конечно пусть, только писать про это хабрапосты совсем не обязательно :) У меня тоже есть маленький самопальный язык с самопальной компиляцией (трансляцией?) в самопальный байткод с его самопальной интерпретацией, и всё это трудится на моём маленьком продакшене как простенькая числодробилка-песочница, но бежать писать посты про это я не собираюсь, там всё равно ничего интересного или уникального)
Алсо, я вроде где-то читал, что refresh token отдавать юзеру вообще нельзя, что лишь добавляет путаницы в моём понимании
От обычного сайта обычный пользователь будет требовать, чтобы его не разлогинивало. Из-за этого безопасность с короткоживущими токенами СНИЖАЕТСЯ: для постоянного автоматического релогина потребуется хранить пароль (или аналогичную инфу (refresh token?)) в открытом виде где-то рядом с токеном, и его с радостью уведёт злоумышленник вместе с токеном (mitm в эпоху повсеместного https почти нереален, скорее всего будет какой-нибудь RCE/XSS или тупо физический доступ к устройству). Придётся везде менять все пароли, похожие на утёкший. А вот если злоумышленнику попадёт классический долгоживущий токен, то достаточно будет просто удалить его из списка действительных.
Буду рад узнать, что я в чём-то не прав.
секундминут (refresh token ведь тоже однажды протухнет? Или я чего-то не понимаю?), то тогда почему бы не тупо посылать пароль (или другую информацию для логина) в каждом запросе, благо HTTPS это безопасно позволяет?)Или существуют случаи, когда «authorisation sever» и сервер, читающий и проверяющий JWT — не один и тот же сервер? Я с таким ещё ни разу не сталкивался. (Не считая кучки микросервисов, спрятанных за некой единой точкой входа — тогда можно применить схему от fuCtor ниже, и JWT для пользователя опять бесполезен)
UPD: ой, тред не читай @ сразу отвечай, ниже то же самое спросили
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition? :)
Во-вторых, все три пункта ничего не значат. Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json, в котором есть и защита от cross-origin, и не используются сторонние библиотеки, и весь ввод фильтруется/экранируется, только какой толк от всего этого, если там разработчик тупо забыл прописать проверку доступа и любой пользователь, узнав про существование этого API, может изменить или в особо запущенных случаях даже прочитать пароль любого другого пользователя?)
Именно это я сам и писал аж позавчера.)