Где лучше хранить JWT?

Question

[Александр Мелентьев]

Здравствуйте!
Задался вопросом, всё же есть ли "серебряная пуля" в данном вопросе? localStorage или Cookie? Или что-то еще?
На текущий момент я храню JWT в зашифрованных cookie, параллельно со стороны сервера передаю токен в Authorization в Header.
Пример кода выложил на Git

Answer 1

[xmoonlight]

Где угодно, но в зашифрованном виде и с флагами secure и http-only.

Доп.защита: Можно разместить в localStorage контрольную сумму полученного токена и тупо проверять его наличие в js и на соответствие конкретному значению, привязанному к клиенту. Любое обращение без подписи запроса этой КС - фиксировать как нарушение и блокировать учётку.

Главное - привяжите токен к клиенту через fingerprint2.js при двухфакторной аутентификации клиента.

Чтобы при хищении даже всех кук (например, через сторонние расширения), они были бы попросту бесполезны, "отпечаток" клиента передавайте при:
1. Авторизации (только двухфакторная аутентификация: почта, смс, GA и т.п.),
2. При смене ip-адреса
3. При смене user-agent
4. По истечению срока давности
И обязательно это всё через шифрование своим публичным "ключом" сервера (помимо https!).

Comments

[Александр Мелентьев]

Спасибо!

[xmoonlight]

Александр Мелентьев, Не за что.
И, не забудьте, что смена токена - должна производиться только с наличием валидного предыдущего токена!
Это крайне важно: никогда и нигде не разрывать, созданную на этапе аутентификации, текущую защищённую "цепь" обмена данными!

[grabbee]

Для чего шифровать JWT ? - он не предназначен для конфиденциальной информации(ошибка 1). Токен изначально самоподписанный, ему не к чему сторонние подписи и ключи. Вы перечислили плохие практики для JWT (скорее банально троллинг). JWT по своей сути хранится считанные минуты.

Всё вами перечисленное привязывается к сессии когда необходима вся эта защита. Сам токен/ID сессии вкладывается внутрь JWT с любой другой необходимой информацией. Вы чешете горло через анус.

[xmoonlight]

Артём Петренков,
1.Про куки - да, но я думал, что здесь все адекватные и понимают где и о чём идёт речь. ;))
2. Непонятная - только для вас. Учите работу https!

Итог: Садитесь, 2! :))

[xmoonlight]

grabbee, я описал то, без чего защита jwt невозможна в принципе.
Ваши сравнения - это сравнения вашего интеллекта и знаний с тем самым местом на букву А.

[xmoonlight]

Артём Петренков,

Разумеется, все вокруг дураки

Вы - это точно, а другие - решают сами.
Ещё раз: Учите работу https!

самопровозглашённый эксперт

опять же, только с вашей точки зрения: ДВОИШНИКА Артём Петренков 'а.

[xmoonlight]

Артём Петренков,

я бы попросил относиться уважительно. Оценки мне не нужно ставить, я сам понимаю, что к чему.

все ваши промахи - приводить не буду...
Только последние приведу: не пишите про "дураков" и "самопровозглашённых экспертов", и будет всё чуть лучше.
Тем более, что Вы сами понимаете: что-к-чему.
Кратко: Артём Петренков, Вам очень далеко расти до оценочных суждений.

[grabbee]

xmoonlight, зачем защищать JWT ? Я вроде с этого начал. Откройте хоть сраную википедию.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Как правило, используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.

Он изначально безопасен. Его не нужно защищать. В нем подпись изначально имеется. Вы не понимаете сути и путаете новичков. JWT не должен шифроваться по определению. Там нет и не должно быть конфиденциальной информации. Вы тролль самый обычный.

[grabbee]

xmoonlight, У хабра новая политика?) троллить Пользователей и постить Холиварные темы? Вы идете ко дну или уже там по элементарным причинам и такая "новая политика" вас точно не спасет.

[xmoonlight]

grabbee, Скажу кратко: любой серверный токен клиента - это всегда проблема его защиты со стороны сервера.

Он изначально безопасен. Его не нужно защищать. В нем подпись изначально имеется. Вы не понимаете сути и путаете новичков. JWT не должен шифроваться по определению. Там нет и не должно быть конфиденциальной информации.

Он вообще не безопасен! Взгляните хотя бы на мат.алгоритм!
Тролль - это Вы.
Не учите людей "дырам"!

Без привязки к клиенту - токен работоспособен на любом клиенте! Это Вы называете "безопасен"?!)))

[xmoonlight]

Артём Петренков,

Злоумышленник может легко увести отпечаток и подделать его на своём клиенте.

Не может! В этом и суть.

[xmoonlight]

Артём Петренков,

я бы и вам не рекомендовал высказывать оценочные суждения.

это просто ответка на ваше поведение.

[xmoonlight]

Артём Петренков,

Какой конкретно из стандартных алгоритмов подписи JWT небезопасен? HMAC, RSA, ECDSA или SHA1?

Снова чушь!
Учите мат. часть! Как именно выписывается такой токен, что необходимо и прочее...

[grabbee]

xmoonlight, это токен авторизации. Он авторизует всё у кого он есть. Привязка к сессии или к клиенту да к чему угодно. Вставляете в тело токена свою привязку и всё. Он работает только с тем, к чему привязан, без вашей всей попоболи. Вы не понимаете сути JWT.

[xmoonlight]

grabbee, понимаю, поэтому и написал про fingerprint, чтобы такого - не было.

[Анатолий Евладов]

xmoonlight, А можно пожалуйста не спамить сообщениями? Спасибо!
Далее, клиентские библиотеки видимо имелись в виду именно как работающие в "браузере". Естественно если подписывать JWT в браузере - клиент сможет сделать с ним всё что угодно.
Впредь прошу ваши "не оценочные" мнения поддерживать ссылкой на официальное пояснение документации JWT.
P.S. Используем JWT, храним в куках. Используем в варианте Refresh & Access ключей, т.е. клиенту отдается два токена. Refresh используется для получения Access и только этого. Access живет пару минут и хранит "общие" данные клиента который могут потребоваться внутренним сервисам чаще всего и которые не являются "приватными" и "закрытыми". Т.е. UserID, Login, и т.п. вещи. Он же используется для проверки что пользователь авторизован.

[xmoonlight]

Анатолий Евладов, я отвечаю на вопросы, а не спамлю.
Речь шла про хищение jwt-токена.
Вариант в "чистом" виде - никак не защищает куки от использования на стороне.

[Анатолий Евладов]

В ситуации с хищением Access JWT токена при наличии в нем того же IP адреса(даже если он динамический) не происходит ровным счетом ничего. Точнее происходит - запрос нового токена со стороны сервера т.к. этот недействительный. Итого - ломатель ничего не достигает. Если же у вас там и запрос пришел с клиентского IP - то у клиента проблемы явно серьезней чем уведенный токен.
Единственное что может быть не очень - так это передавать IP например в открытом виде. Ну так его то как раз можно и зашифровать, все равно при проверке его можно просто зашифровать еще раз и сравнить. Но - это уже относится к проверке валидности самого токена.

[xmoonlight]

Анатолий Евладов,

Точнее происходит - запрос нового токена со стороны сервера т.к. этот недействительный

по какому критерию?

[Анатолий Евладов]

xmoonlight,

при наличии в нем того же IP адреса

[Александр Мелентьев]

В моём примере как раз есть момент, когда я шифрую данных в куках, при этом передаю JWT в заголовке не зашифрованный.
Просто какая-то привычка что-ли шифровать всё в куках

[grabbee]

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

[Александр Мелентьев]

grabbee, всегда придерживаюсь принципу, хранить в JWT только уникальный идентификатор пользователя. А все остальное, если нужно, подтягивать по нему из БД

[bro-dev]

Александр Мелентьев, тогда теряется смысл jwt, его суть в том чтобы при каждой авторизации не лезть в базу.

[xmoonlight]

Артём Петренков,

Где исполняется fingerprint2.js

в браузере (на клиенте).

Всё. Теперь его нельзя подделать. Дополнительно шифровать не нужно.

В чистом виде без привязки к клиенту - да. Иначе - нужно.

[xmoonlight]

Анатолий Евладов, не всегда ip адресу можно доверять: особенно, внутри одной организации.

[Рональд Макдональд]

grabbee,

Вы тролль самый обычный.

Нет, он просто абсолютно некомпетентен в любом вопросе, на который берётся отвечать.

[Александр Мелентьев]

bro-dev, я и не лезу. При авторизации формирую JWT, в него вношу идентификатор пользователя.

[Виталий Хоменко]

Используем в варианте Refresh & Access ключей, т.е. клиенту отдается два токена. Refresh используется для получения Access и только этого. Access живет пару минут и хранит "общие" данные клиента который могут потребоваться внутренним сервисам чаще всего и которые не являются "приватными" и "закрытыми". Т.е. UserID, Login, и т.п. вещи. Он же используется для проверки что пользователь авторизован.

Анатолий Евладов, что происходит в момент кражи пары токенов? Как вы определяете, что токены угнаны? А если два разных клиента пользуются одной парой токенов, что происходит? Просто пытаюсь понять, как вы разруливаете самые сложные ситуации

[bro-dev]

Александр Мелентьев, Если у вас в jwt только ид, как вы проверите при запросе на апи есть у пользователя туда доступ или нет? вам нужно обратится в базу а это и есть потеря смысла jwt.

[Александр Мелентьев]

bro-dev, просто если хранить доступы в jwt, теряется оперативность. Ты доступ у пользователя забрал, а в jwt он ещё прописан, и пропадет он только после переавтоизации.

[bro-dev]

Александр Мелентьев, Ну так да и есть, именно поэтому jwt мало где применяют, потому что токен не отозвать, но можно пойти на компромисс и сделать аксес токен 10 минут, тогда время отзыва будет максимум эти 10 минут. Есть второе решение это аксес токен например час, но на всех инстансах хранить черный список отозванных токенов за последний час.

[Александр Мелентьев]

bro-dev, опять же, если храним черный список, мы к нему будем каждый раз обращаться. Замкнутый круг))) В любом случае обращаться к бд придется. Но как верно подмечено, все зависит от кейса. Но я всё же за оперативность

[bro-dev]

Александр Мелентьев, значит нужно отказаться от jwt и вернутся к классическим сессиям, и спрашивать нечего не ук ого не надо будет, уже 100 раз пройденный путь и даже на самом задрипанном яп будут либы, а черный список за 1 час будет даже у ютуба не большой, со всеми вытекающими.

[Александр Мелентьев]

bro-dev, а если сервис использует не только веб, но android/ios приложения?

[xmoonlight]

Александр Мелентьев, никакой разницы абсолютно в логике - нет.

[Анатолий Евладов]

Виталий Хоменко, да собственно писалось уже. Если запрос идет не с того IP то берем и просто игнорим - это вообще не проблема. Т.к. токен в данном случае сразу становится не валидным. Если же пришел запрос с того же адреса что и ожидалось - то у пользователя проблемы намного бОльшие чем просто уведенный аккаунт. Да, в компаниях технически оно может стать проблемой, т.к. все выходят через один и тот же адресс, но... это извините, уже проблемы компании которая у себя такое допустила.
Просто стоит понимать что есть безопасность, а есть - избыточность. Вам нужно обеспечить безопасность своих данных, а не подтирать за пользователем везде где можно и совсем не нужно.
Нужно понимать, что JWT создавался что бы не делать кучи лишних "чихов" в БД. Т.е. рассматривать его имеет смысл именно в рамках больших сервисов с большим количеством запросов в секунду. Для мелких - этот вопрос не стоит так остро, можно и сделать дополнительный запрос в БД.
Два разных клиента одной парой токенов пользоваться не могут - собственно по причине того что там IP прописан, да и RefreshTokenID мы туда тоже пихаем. В итоге всегда можно увидеть с какой "сессии" шли запросы. в ЛК пользователя есть список подобных токенов, их можно просто отозвать. Но если у нас срабатывает ситуация что приходит не валидный access токен, мы просто сообщаем что он не валиден. Далее уже сам клиент должен запросить создание нового подобного токена. Если и эта операция не успешна - тогда уже потребуется вводить логин-пароль для получения валидного Refresh токена.
Да, можно конечно взломщику все это проигнорить и продолжать слать не валидный access/refresh токен, но... толку то с того? N подобных запросов в течении минуты - и мы отзываем Refresh токен автоматиечки и отправляем на почту клиента уведомление что подобное происходит, дальше собственно уже не наша забота. Можно вообще аккаунт временно блочить если подобный функционал написан. Вариантов масса. Тут просто надо понимать что JWT - не панацея. Как собственно и любые куки и сессии. Надо понимать что JWT в первую очередь создавался что бы снизить нагрузку на БД при большом гарантированном количестве запросов от клиентов. В итоге, мы, используя JWT можем делать не ~5к запросов в секунду в БД, а всего в среднем около 20, что согласитесь, намного меньше)

[Виталий Хоменко]

а если сервис использует не только веб, но android/ios приложения?

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

[xmoonlight]

Виталий Хоменко, локальное хранилище, токен - вот и вся сессия.

[Виталий Хоменко]

Анатолий Евладов, я вас понял. У вас вариант, который создает неудобства для пользователя - его будет разлогинивать каждый раз при смене точки доступа в интернет. Если для фин. проектов это норма, там безопасность превыше всего и нужно разлогинивать даже при неактивности пользователя. То как быть с обычными проектами? Никак, нельзя привязываться к IP, иначе как тогда объяснять, почему пользователя выкидывает с личного кабинета по три раза за день когда он с ноутом ездит по городу, а он ведь поставил галочку "запомнить меня".

Но даже при вашем решении, если злоумышленник сворует токены пользователя и сможет(как-то) слать запросы с его IP скрытно, то разлогинит запоздалого пользователя, а злоумышленник продолжит пользоваться ворованными токенами.

Спасибо за развернутый ответ!

[Виталий Хоменко]

https://gist.github.com/zmts/802dc9c3510d79fd40f9d...
Тут очень много размышлений на эту тему. Понимаю, что идеального решения нет.

Answer 2

[Дмитрий Беляев]

В принципе это относится не только к JWT, но и к любым данным, которые критично не дасть украсть.
Такие данные лучше всего хранить в secure http-only cookie. С secure думаю понятно, такая кука будет отправляться на сервер только по https, что снизит вероятность угона путем подслушивания трафика. А вот с http-only причина та же, почему не стоит использовать localStorage - не http-only кука доступна из JS, из любого JS загруженного на странице.
Что в этом плохого? Вы уверены во всех скриптах, подключенных к Вашей странице? А если сторонний сервер был взломан? А если у пользователя стоит вредоносное расширение, подменяющее определенные скрипты на всех сайтах? Соберет такой вредонос из localStorage токены Ваших пользователей, а Вам потом с ними разбираться, почему их взломали.

Comments

[Александр Мелентьев]

То есть в принципе я всё правильно делаю?

if encoded, err := utils.C.Encode("cookie-jar", value); err == nil {
		token := fmt.Sprintf("Bearer %s", tokenString)
		w.Header().Set("Authorization", token)
		cookie := &http.Cookie{
			Name:     "cookie-jar",
			Value:    encoded,
			Domain:   ".localhost",
			Path:     "/",
			Expires:  expirationTime,
			HttpOnly: true,
			// Secure:   true,
		}
		http.SetCookie(w, cookie)
	}

Secure пока закомментировал, так как при разработке сертификат HTTPS не используется.
Так же, то что идёт в Value шифруется с помощью SecureCookie от Gorilla

[Дмитрий Беляев]

Александр Мелентьев, да, все верно

Secure пока закомментировал, так как при разработке сертификат HTTPS не используется.

Не особо силен в Go, но разве в нем нет условной компиляции, чтоб выдавать разные значения в зависимости от типа сборки/env-переменных?

[Александр Мелентьев]

Дмитрий Беляев, кстати, да, пойду добавлю env. Спасибо!

Answer 3

[Ruslan Radionov]

+ к тому, что сказали. Нужно ограничивать время жизни токена. И если даже уведут, то есть вероятность не успеть им воспользоваться. Такой токен обычно называют access token. И он сам себя продлить никак не должен уметь.

Answer 4

[Sanes]

SessionStorage + HTTPS и TTL контролировать на сервере.
Может оверхед конечно. Но ничего лучше для параноиков пока не придумано.

Comments

[Александр Мелентьев]

При закрытии вкладки, и открытии новой - сессия хранилища будет завершена. Это не юзерфрендли. Не вариант

[Sanes]

Александр Мелентьев, ну выдавай тогда на каждый запрос новый токен. Или через какой-то промежуток времени.

[Александр Мелентьев]

Sanes, так и делаю. При каждом запросе токен обновляется. Так же его жизнь ограничена, то есть если в течении 15 минут ничего не делать, Cookie превратятся в тыкву, как и JWT собственно.

[Sanes]

А куки тут при чем? А если приложение не умеет с ними работать? Ну мало-ли какое.

[Sanes]

Александр Мелентьев,
Почта России вообще не заморачивается
https://otpravka.pochta.ru/specification#/authoriz...

[JhaoDa]

Sanes, не заморачивается, потому что это server-to-server API, никто в здравом уме не потащит это в браузер.

[Sanes]

JhaoDa, никто в здравом уме не передает логин/пароль в открытом виде.

[JhaoDa]

Sanes, вагон и маленькая тележка разных API так устроены. Что логин-пароль, что какой-то ключ — разница не так уж принципиальна, тем более, что это не логин-пароль от ЛК Почты.

[Sanes]

JhaoDa, первый раз такое извращение вижу. По-человечески могли бы сделать. Управление своими ключами в ЛК.

[JhaoDa]

Sanes, хотя не, обманул — в случае Почты это именно логин-пароль от ЛК. Плюс ключ, который выдаётся после заключения договора и который можно менять в ЛК. Впрочем, как сказал выше, логин-пароль в случае server-to-server — это не страшно.

[Sanes]

JhaoDa, да не суть, логин:пароль передавать это жесть.

[JhaoDa]

Sanes, большая часть API — жесть. Сад бут труе.

[Sanes]

JhaoDa,
Именно такое вижу первый раз. Обычно предоставляют возможность генерирования и удаление ключей API.

Answer 5

[nikandfor]

Токены вроде лучше не класть в куки, чтобы вредоносный javascript не мог ими воспользоваться.

Comments

[SagePtr]

Вредоносный javascript и не должен иметь доступа к куки (т.к. httpOnly)