Как сделать безопасную авторизацию с RSA, AES и JWT?

Question

Прежде всего, позвольте мне объяснить вам, что я себе представляю:

Давайте представим, что Боб хочет получить Авторизат от Алисы (Classi c Пример), в моем примере Алиса - сервер.

Давайте представим себе, что Боб и Алиса уже получили каждый ключ RSA (4096).

Итак, Бобс предпримет следующие шаги:

1. Подписать кредиты (открытый текст) с помощью SHA512 и его закрытый ключ
2. Шифрование подписанных данных и кредитов с помощью AES CB C 256
3. Шифрование ключа AES с помощью RSA
4. Отправка данных Алисе

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

После того, как Алиса проверила, что это Боб, она сгенерирует токен JWT и подпишет его своим закрытым ключом и вернет его в авторизации заголовка ответа.

JWT получил TTL от 3600.

Пока все хорошо, но мой вопрос: как нам защитить JWT от кражи?

Конечно, он подписан, поэтому его нельзя изменить (за исключением того, что Attacker получил Pr ivate Key с сервера, но, боже мой, его все равно кончилось).

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

Я думал о двух вариантах:

Вариант 1: Всегда отправлять кредиты и расшифровывать, чтобы проверить Боба.

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

Вариант 2: Отправка уникального идентификатора и подтверждение его с устройства Bobs (зашифровано, такая же проблема, как у варианта 1)

Что мы могли бы сделать, чтобы защитить это?

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

Спасибо ты уже для тебя Ответы

Answer 1

Пока все хорошо, но мой вопрос в том, как нам защитить JWT от кражи?

Как вы уже узнали, это https

Давайте представим, что он сможет взломать HTTPS и украсть токен

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

Предположим, что канал небезопасен, вы можете, например, подписать каждое сообщение отдельно (с незащищенным каналом недостаточно защитить только заголовок) ,

Answer 2

Что ж, если Алиса не уверена в том, кто отправляет запрос, то так же, как и Боб, так что это двусторонняя проблема, Никто не может быть уверен в идентичности другого, Вы можете исправить это с помощью подписанный сертификат из центра сертификации. Когда вы отправляете с подписью сертификат, а этот сертификат подписывается с помощью закрытого ключа центра сертификации (третьей стороны), который обеспечивает безопасность соединения между клиентским сервером и предотвращает любые изменения.