Что делать, если JWT украден?

Ответ 1

Я являюсь автором библиотеки node, которая обрабатывает аутентификацию на некоторой глубине, express-stormpath, поэтому я буду звонить здесь с некоторой информацией.

Во-первых, JWT, как правило, НЕ зашифрованы. Хотя существует способ шифрования JWT (см. JWEs), это не очень распространено на практике по многим причинам.

Далее, любая форма проверки подлинности (с использованием JWT или нет) может подвергаться атакам MitM-атак (man-in-the-middle). Эти атаки происходят, когда злоумышленник может ПРОСМОТРЕТЬ ваш сетевой трафик, когда вы делаете запросы через Интернет. Это то, что может видеть ваш интернет-провайдер, NSA и т.д.

Это то, что SSL помогает предотвратить: путем шифрования трафика NETWORK с вашего компьютера → на каком-либо сервере при аутентификации, сторонняя организация, контролирующая сетевой трафик, НЕ может видеть ваши токены, пароли или что-то в этом роде, re как-то может получить копию секретного ключа SSL сервера (маловероятно). Именно по этой причине SSL является ОБЯЗАТЕЛЬНЫМ для всех форм аутентификации.

Скажем, однако, что кто-то может использовать ваш SSL и способен просматривать ваш токен: ответ на ваш вопрос заключается в том, что ДА, злоумышленник сможет использовать этот токен, чтобы выдать себя за вас и сделать запрос на ваш сервер.

Теперь, когда протоколы входят.

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

ОДНАКО, сами JWT не имеют ничего общего с "безопасностью". Для всех намерений и целей JWT более или менее идентичны ключам API: просто случайные строки, которые вы используете для аутентификации на каком-то сервере где-то.

Что делает ваш вопрос более интересным, используется протокол (скорее всего, OAuth2).

Как работает OAuth2, он предназначен для предоставления клиентам TEMPORARY токенов (например, JWT!) для аутентификации только для ТОЛЬКО КРАТКОГО ПЕРИОДА!

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

С помощью OAuth2 вы должны повторно аутентифицировать себя с сервером так часто, предоставляя свои учетные данные пользователя/пароля или API, а затем получая токен обратно в обмен.

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

Надеюсь, это поможет ^^

Ответ 2

Я знаю, что это старый вопрос, но я думаю, что я могу отбросить свои $ 0,50 здесь, возможно, кто-то может улучшить или предоставить аргумент, чтобы полностью отказаться от моего подхода. Я использую JWT в RESTful API через HTTPS (ofc).

Чтобы это работало, вы всегда должны выдавать краткосрочные токены (зависит от большинства случаев, в моем приложении я фактически устанавливаю требование exp на 30 минут, а ttl на 3 дня, чтобы вы могли обновлять этот токен, пока его ttl все еще действует, а токен не занесен в черный список)

Для authentication service, чтобы аннулировать токены, я хотел бы использовать слой кэша в памяти (redis в моем случае) в качестве JWT blacklist/JWT blacklist ban-list JWT blacklist впереди, в зависимости от некоторых критериев: (я знаю, что он нарушает RESTful философия, но сохраненные документы действительно недолговечны, поскольку я помещаю их в черный список за оставшееся время их существования - ttl claim-)

Примечание: жетоны в черном списке не могут быть автоматически обновлены

• Если user.password или user.email были обновлены (требуется подтверждение пароля), служба аутентификации возвращает обновленный токен и делает недействительным (черный список) предыдущий (ие) список, поэтому, если ваш клиент обнаружит, что идентификация пользователя каким-либо образом была скомпрометирована, вы можете спросить этот пользователь, чтобы изменить свой пароль. Если вы не хотите использовать черный список для него, вы можете (но я не рекомендую вам) проверять утверждение iat (выданное в) по отношению user.updated_at полю user.updated_at (если jwt.iat < user.updated_at тогда JWT недействительный).
• Пользователь намеренно вышел из системы.

Наконец вы проверяете токен как обычно.

Примечание 2: вместо того, чтобы использовать сам токен (который очень длинный) в качестве ключа кэша, я предлагаю сгенерировать и использовать токен UUID для утверждения jti. Это хорошо, и я думаю (не уверен, так как это только что пришло мне в голову), вы также можете использовать этот же UUID в качестве токена CSRF, вернув с ним secure/non-http-only cookie и должным образом реализовав X-XSRF-TOKEN Заголовок X-XSRF-TOKEN с использованием js. Таким образом, вы избегаете вычислительной работы по созданию еще одного токена для проверок CSRF.

Ответ 3

Я также сталкивался с этой проблемой, связанной с безопасностью в прошлом, но я могу сделать это в Laravel. Симплей делает одно промежуточное ПО и проверяет Origin таким образом.

<?php
namespace App\Http\Middleware;
use Closure;
class CheckOrigin
{
    public function handle($request, Closure $next)
    {
        if($request->header('Origin') != 'http://yourapihost.com') {
            return response()->json([
                'meta' => [
                    'message' => 'You are Unauthorize person.',
                    'status_code' => 401,
                    'status' => false,
                ],
            ],401);
        }
        return $response;
    }
}

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

Ответ 4

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

1) rdegges добавил отличное замечание, что JWT не имеет ничего общего с "безопасностью" и просто проверяет, не ошибся ли кто-нибудь с полезной нагрузкой или нет (подписание); SSL помогает предотвратить от нарушений.

2) Теперь, если ssl также каким-то образом скомпрометирован, любой подслушивающий может украсть наш токен на предъявителя (JWT) и выдать себя за подлинного пользователя, следующий шаг уровня, который можно сделать, - найти "доказательство владения" JWT у клиента,

3) Теперь, при таком подходе, презентатор JWT обладает определенным ключом подтверждения владения (POP), который получатель может криптографически подтвердить, является ли запрос от того же аутентичного пользователя или нет.

Я сослался на статью Proof of Possesion и убедился в этом.

Я буду в восторге, если смогу что-нибудь внести.

Приветствия (у)