Если вы можете декодировать JWT, как они защищены?

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

Ответьте на свой комментарий: Я не уверен, насколько правильно понимаю ваши комментарии. Чтобы быть уверенным: знаете ли вы и понимаете цифровые подписи? Я просто кратко объясню один вариант (HMAC, который является симметричным, но есть и многие другие).

Предположим, Алиса хочет отправить JWT Бобу. Они оба знают общий секрет. Мэллори не знает эту тайну, но хочет вмешаться и изменить JWT. Чтобы избежать этого, Алиса вычисляет Hash(payload + secret) и добавляет это как подпись.

При получении сообщения Боб может также рассчитать Hash(payload + secret) чтобы проверить соответствие соответствия. Если, однако, Мэллори что-то меняет в содержании, она не может вычислить соответствующую подпись (это будет Hash(newContent + secret) ). Она не знает секретов и не имеет возможности узнать это. Это означает, что если она что-то изменит, подпись больше не будет соответствовать, и Боб просто не примет JWT.

Предположим, я посылаю другому человеку сообщение {"id":1} и подписываю его с помощью Hash(content + secret) . (+ просто конкатенация здесь). Я использую функцию SHA256 Hash, и подпись я получаю: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c . Теперь ваша очередь: играть роль Мэллори и попытаться подписать сообщение {"id":2} . Вы не можете, потому что не знаете, какой секрет я использовал. Если я полагаю, что получатель знает секрет, он МОЖЕТ рассчитать сигнатуру любого сообщения и проверить, правильно ли это.

Вы можете перейти к jwt.io , вставить свой токен и прочитать содержимое. Это изрядно для многих людей изначально.

Короткий ответ заключается в том, что JWT не относится к шифрованию. Он заботится о валидации. То есть, он всегда может получить ответ для «Использовать содержимое этого токена»? Это означает, что манипулирование пользователем токена JWT бесполезно, потому что сервер будет знать и игнорировать токен. Сервер добавляет подпись на основе полезной нагрузки при выдаче токена клиенту. Позже он проверяет полезную нагрузку и соответствующую подпись.

Логичным вопросом является то, что является мотивацией не к самому себе с зашифрованным содержимым?

1. Простейшая причина заключается в том, что она предполагает, что это проблема решена по большей части. Например, если вы работаете с клиентом, например с веб-браузером, вы можете хранить токены JWT в secure + httpsOnly cookie secure + httpsOnly (не может быть прочитан Javascript +, не может быть прочитан HTTP) и разговаривает с сервером через зашифрованный канал (HTTPS). Как только вы узнаете, что у вас есть безопасный канал между сервером и клиентом, вы можете безопасно обменивать JWT или все остальное, что хотите.

2. Это просто. Простая реализация упрощает принятие, но также позволяет каждому слою делать то, что он делает лучше всего (пусть HTTPS обрабатывает шифрование).

3. JWT не предназначен для хранения конфиденциальных данных. Когда сервер получает токен JWT и проверяет его, он может свободно искать идентификатор пользователя в своей собственной базе данных для получения дополнительной информации для этого пользователя (например, разрешения, почтовый адрес и т. Д.). Это уменьшает размер JWT и предотвращает непреднамеренную утечку информации, потому что все знают, что не хранить конфиденциальные данные в JWT.

Это не слишком отличается от того, как работают cookies. Файлы cookie часто содержат незашифрованные данные. Если вы используете HTTPS, тогда все будет хорошо. Если вы этого не сделаете, рекомендуется зашифровать сами cookies. Не делать этого будет означать, что возможна атака «человек в середине» – прокси-сервер или интернет-провайдер читает cookies, а затем повторяет их позже, притворяясь вами. По аналогичным причинам JWT следует всегда обменивать на безопасном уровне, таком как HTTPS.

Содержимое в токенах json web (JWT) не является неотъемлемо безопасным, но есть встроенная функция проверки подлинности токена. JWT – три hashа, разделенные периодами. Третья – подпись. В системе открытого / закрытого ключа эмитент подписывает подпись токена с закрытым ключом, который может быть проверен только посредством соответствующего открытого ключа.

Важно понимать различие между эмитентом и верификатором. Получатель токена отвечает за его проверку.

В безопасном использовании JWT в веб-приложении есть два важных шага: 1) отправить их по зашифрованному каналу и 2) проверить подпись сразу после ее получения. Асимметричный характер криптографии с открытым ключом делает проверку подписи JWT возможной. Открытый ключ проверяет, что JWT был подписан его соответствующим личным ключом. Никакая другая комбинация клавиш не может выполнять эту проверку, тем самым предотвращая попытки олицетворения. Следуйте этим двум шагам, и мы с математической гарантией можем гарантировать подлинность JWT.

More reading: Как открытый ключ проверяет подпись?

Только закрытый ключ JWT, который находится на вашем сервере, расшифрует зашифрованный JWT. Те, кто знает privateKey, смогут расшифровать зашифрованную JWT.

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

Данные внутри JWT подписаны и зашифрованы, это не значит, что они безопасны. JWT не предоставляет гарантии для конфиденциальных данных.

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

Насколько мне известно, JWT не обеспечивает безопасность.

благодаря