что случится с JWT, если кто-то получит мой закрытый и открытый ключ? - PullRequest
0 голосов
/ 14 сентября 2018

Мне кажется, что если мой закрытый и открытый ключи скомпрометированы (который я использую для подписи и проверки JWT), что любой может независимо генерировать токены JWT для себя, чтобы использовать их в моем API?

Тогда как нас другой стороны, если я сам сгенерирую свои собственные токены и сохраню справочную таблицу с «односторонним хэшированием идентификатора пользователя» => «токен», то если кто-то проникнет в мою систему, он не сможет генерировать токеныиспользовать в моем API, и они также не смогут использовать токены (потому что они не будут знать, какой токен принадлежит тому или иному пользователю)

Если кто-то проникнет в вашу систему и он все еще безопасен, то высделал защищенную систему;не о чем беспокоиться.

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

Ответы [ 3 ]

0 голосов
/ 14 сентября 2018

Принимая во внимание, что с другой стороны, если я сам сгенерировал свои собственные токены и сохранил справочную таблицу с «односторонним хэшированным идентификатором пользователя» => «токен»,

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

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

Если вы храните их в хранилище данных, теперь вы должны отслеживать срок действия в хранилище данныхтакже.Билеты / жетоны могут иметь встроенный срок действия.Хорошая вещь о билетах / жетонах - клиент держит их.Вы можете закончить сеанс быстрее, чем аутентификация.Т.е. часто вы получаете билет, который может позволить вам войти в систему в течение 2 часов, но веб-сервер может прервать сеанс через 10 минут, чтобы уменьшить использование памяти.Когда вы получите доступ к веб-серверу через 15 минут, он увидит ваш билет / токен, увидит, что он все еще действителен, и создаст новый сеанс.Это означает, что в любой момент времени сервер отслеживает гораздо меньше незанятых пользователей.

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

Если кто-то проникнет в вашу систему и она все еще безопасна, значит, вы сделали защищенную систему;не о чем беспокоиться.

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

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

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

https://en.wikipedia.org/wiki/Hardware_security_module

0 голосов
/ 15 сентября 2018

Мне кажется, что если мой закрытый и открытый ключи скомпрометированы (который я использую для подписи и проверки JWT), что любой может независимо генерировать токены JWT для себя, чтобы использовать их в моем API?

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

0 голосов
/ 14 сентября 2018

Мне кажется, что если мой частный и открытый ключи скомпрометированы (который я использую для подписи и проверки JWT), что каждый может независимо генерировать токены JWT для себя, чтобы использовать их в моем API?

Да, это правильно.


Открытые ключи предназначены для открытых и могут распространяться.

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

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

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