Поясните про JWT

Если у злоумышленника есть возможность украсть access-токен, то что мешает украсть и refresh-токен, а затем намутить себе собственных access-токенов?

Ничто не мешает. Но в теории при генерации refresh-token ты можешь использовать ip и/или user-agent пользователя, который залогинился, что уже сужает круг злоумышленников.

Ничто не мешает. Но в теории при генерации access-token в качестве secret phrase ты можешь использовать ip и/или user-agent пользователя (можно и в payload эти поля добавить), который залогинился, что уже сужает круг злоумышленников.

refresh-token можно генерировать новый при каждом входе, но более безопасно сделать так, чтобы его хватало на N раз. Хотя, более безопасно или нет, наверно зависит от твоей внутренней логики.

ip

Плз, не надо,

Жутко бесит, когда сервисы разлогинивают при смене ip.

В наше время ip не является идентификатором юзера

В наше время ip не является идентификатором юзера

А что является? Как минимум геолокацию можно использовать, но это такое себе.

Если у злоумышленника есть возможность украсть access-токен, то что мешает украсть и refresh-токен

Тут три обстоятельства. Во-первых refresh токен используется реже, т.е. не в каждом запросе, т.о. вероятность его перехвата меньше. Кроме того канал получения access-токена может быть другим (не тем который ты сумел прослушивать). Во-вторых его можно отозвать в случае проблем и это связано с п.3 что клиенту не нужно палить свои телефоны-пароли каждый раз, а только при получении refresh-токена.

Ничего из этого, в наше время юзер может использовать vpn или физически перемещаться между странами по 5 раз на дню

то что мешает украсть и refresh-токен

• как сказали выше, основную часть времени он просто «лежит» и никуда не передаётся
• есть схемы, когда refresh-токен не покидает бэк
• контроль ip/фингерпринта, т.е. при угоне refresh-токена разлогинивать пользователя

есть схемы, когда refresh-токен не покидает бэк

О, про это можно поподробнее?)

Сейчас уже не найду такую схему, по-моему встречал её или в статье или в обсуждении на хабре. Контекст тоже уже не вспомню.

Это прочитай: https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc

Всё самое полезное про JWT уместили на 1 странице.

Во, что-то подобное и было про хранение refresh на сервере.

Бред какой-то. Всё на каких-то притянутых за уши доводах. Больше похоже на излишнее усложнение, ментально нагружающее программистов. Снизит в итоге безопасность до вообще нуля.

клиенту не нужно палить свои телефоны-пароли каждый раз

существует криптографическая схема SRP — Secure Remote Password, в которой юзер вообще не передаёт свой пароль при логине

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

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

Т.е. если злоумышленник начнёт ломать юзера многочисленными попытками логина, то свежие сессии, которые создаст злоумышленник, вытеснят валидные сессии юзера? Отлично!

Мне ещё раздел «Зачем все это ? JWT vs Cookie sessions» очень понравился, аргументы огонь. А я посоветую почитать вот эту или эту статью, там описана противоположная точка зрения.

Т.е. если злоумышленник начнёт ломать юзера многочисленными попытками логина, то свежие сессии, которые создаст злоумышленник, вытеснят валидные сессии юзера? Отлично!

Не попытками, а логином. Ограничивать кол-во сессий я бы тоже не стал. На этот случай можно отправлять пользователю уведомления, о входе с нового устройства и возможностью закрыть сессии. Но это в теории, на практике обычно всё не так хорошо 😅

Ну насколько мне известно, то если фингерпринт авторизуемого юзера при авторизации не совпадает с фингерпринтом в базе, то должен произойти рефреш токена. И тебя должно вылогинить везде на всех устройствах. И это, типа, минус JWT.

UPD: а на новом устройстве тоже не пустит, должен отправиться 2FA код на почту и всё такое))

Не попытками, а логином

Не суть важно, пусть будет логином. Как это юзера защищает-то?

Ну насколько мне известно, то если фингерпринт авторизуемого юзера при авторизации не совпадает с фингерпринтом в базе, то должен произойти рефреш токена

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

должен отправиться 2FA код на почту и всё такое

Лучше использовать TOTP, т.к. 2FA в виде кода на почту быстро превращается в 1FA в случае, если почту угнали.

Но TOTP тоже не для всякой аудитории подойдёт, к сожалению (если вы делаете клон одноклассников, то тут вы скорее всего в пролёте).

Зачем ты это говно принёс?

Заголовок про JWT, а разделы: «Что такое авторизация/аутентификация», «Как ставить куки ?» О чем этот документ вообще?

Открыл страницу в произвольном месте. Читаем:

определяет несколько зарезервированных имен (iss, aud, exp и другие).

Ошибка. Они не зарезервированы, а зарегистрированы (в реестре). Это работает совсем не так как автор думает. Любой может внести в глобальный реестр новые имена для public клеймов. Любое имя, которым вы наделили claim имеет потенциал к коллизии с будущими именами которые могут быть внесены в реестр. Поэтому в строгом смысле оно должно быть «Collision-Resistant».

дополнительно закодированы в формат base64

Ошибка. Это не base64. Достаточно открыть RFC и убедиться. То есть дурачок с этими JWT токенами на практике не работал.

Дальше читать не стал.

этом случае надо либо отказываться фингерпринтов

Фингерпринт - это вообще глупость. Он не может использоваться ни в каких схемах аутентификации. Откуда этот идиотизм пошел? Я вообще не знаю каких-то применений для фингерпринта кроме с вероятностью 1% показать пользователю баннер релевантный (с вероятностью 2% релевантный), или с вероятностью 1% перепутать человека с другим человеком, и в 98% показать рандомный баннер, раз ничего не совпало. Любой выход концепции фингерпринта за пределы этого применения - тотальная глупость.

Фингерпринт - это вообще глупость. Он не может использоваться ни в каких схемах аутентификации

Вообще согласен, разве что использовать его в следующей роли: при новом логине отсылать автоматически выведенный с клиента фингерпринт (приблизительное местоположение + браузер + IP) для уведомления пользователю на почту (если вообще можно назвать это фингерпринтом).

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

Почему? Есть же сайты где упор сделан на фингерпринт, тот же skladchik.com, который жёстко палит мультиакк по фингерпринту (по идее), и upwork.com.

2FA в виде кода на почту быстро превращается в 1FA в случае, если почту угнали

Ну-у это такое. Если угнали почту, то могут много доступов поиметь и тут мало что спасёт.

Возьмём Authorization Code Flow.

Если сайт генерирует страницы на севере ( не SPA ), то для запроса refresh необходим client_secret, который хранится на сервере.

Если SPA, то есть это: https://www.oauth.com/oauth2-servers/pkce/

Короче имея на руках только refresh token, невозможно получить новый access token.

/thread

Есть же сайты где упор сделан на фингерпринт, тот же skladchik.com, который жёстко палит мультиакк по фингерпринту (по идее), и upwork.com.

Вангую, что у них фингерпринтинг работает тоже не в 100% случаев.

Ну-у это такое. Если угнали почту, то могут много доступов поиметь и тут мало что спасёт.

А вот если 2FA сделано через TOTP и 2FA требуется при логине и смене пароля, то даже угнав почту, ты не сможешь залогиниться и сменить пароль пользователя. А вот если 2FA сделано через отправку кода на почту — сможешь.

О чем этот документ вообще?

Первый день на ЛОР-е? Тут принято отходить от темы и общатсья на смежные.

Не, ну, ты глубже погрузился в JWT и шаришь, а автор пасты на github просто скомпилировал данные из разных источников в одну заметку.

Вангую, что у них фингерпринтинг работает тоже не в 100% случаев.

Ну это да. Ну, серебрянной пули не существует, как оказалось :) За TOTP я не шарю. Чёт сложно выглядит (быстренько погуглил)

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

во-вторых. допустим на данной либе у агента меняется фингерпринт каждые 3 секунды (это реальные факты). у тебя как у администратора проекта или программиста есть положим 100 фингерпринтов. вопрос. что должно заставить его усомниться в том что это ~100 агентов (а не 5)? далее вопрос. если кто-то задался вдруг таким вопросом (с чего бы вдруг?): как они докажут это или опровергнут? даже для того чтобы тест отладочный провести, нужен рефересный идентификатор пользователя, а у нас идентификатор - фингерпринт. у тебя могут быть все фингерпринты - мусор, а могут быть все идеальные, ты никак не узнаешь. чтобы вести контроль над осмысленностью внедренного фингерпринт-решения, нужен второй идентификатор пользователя, который однозначно его идентифицирует, лол.

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

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

Рефреш токен одноразовый. Если его угонят – пользователь заметит при следующей же замене.

Задача не сделать угон невозможным. Угон будет возможен всегда. Задача максимально быстро определить что угон состоялся, чтобы пользователь успел принять меры пока не поздно.

Но как-то непонятно, чем безопасность достигается.

Особо ничем. На текущий момент сделать супер безопасный и _удобный_ сервис для всех разношёрстных устройств не особо то и получится. Отсюда и все эти костыли с рефрешами, https-ми с тонной спама «Важное оповещение системы безопасности».

ПС. Но в конце концов все будут посчитаны и у каждого заместо паспорта будет «личный ключ» с помощью которого всё и будет осуществляться. На работе, например, мы (сотрудники) личные доки не ручкой подписываем, а эцп. ИМНО тоже самое будет у этих ваших гуглов.

Подводя итоги - никакой убер-безопасности по сравнению с сессионными куками использование данного решения не несет? И https для безопасности значит гораздо больше?

Я пилю сейчас внутренний сервис компании (доступен только во внутренней сети, авторизация через ldap), в будущем он возможно станет внешним, но только для ограниченного числа сторудников (не для клиентов). И в этом случае морочиться с jwt особого смысла нет, как я понимаю.

А что является?

Логин. Всё.

Да.

На правах ИМХО - рефреш и аксесс токены разделены только из-за нагрузки. Чтобы, с одной стороны, с каждым запросом не ходить в сервис авторизации (для валидации токена), а с другой - не давать слишком долгоживущих токенов для работы с системой (потому что их инвалидировать невозможно без потери производительности - про две проблемы в программировании, одна из которых инвалидация кеша, ведь все помнят?).

Ну а если про остальное - система аутентификации/авторизации на публичных-приватных ключах уже давно были в том или ином виде (PKIX туда же). Просто решили навести порядок (и не зря, канеш) и договориться о едином виде. До него кажись только SAML и был более-менее стандартный и децентрализованный. Но он же жесть!

они не про безопасность, а про REST, где не должно быть никаких состояний (без кук, короче). JWT состоит из трех сегментов, разделенных точками. Каждый сегмент - это base64 (websafe, те без «/»). В заголовках ничего интересного кроме алгоритма шифрования подписи. В теле обычно user_id по которому мы вытягиваем из базы сессионного пользователя. Ну и последний - подпись, которая генерируется с помощью соли, которая зашита в коде.

Рефреш токены предусмотрены на случай воровства access token’ов, а так же чтобы задать какой-то интервал, аналогичный времени жизни кук… Что касается воровства, то там в тело access token записываешь время его создания, если оно меньше времени последней смены пароля, то токен не валиден. Это чтобы хацкер после смены пароля не мог продолжать чудить

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