Разумно ли запихивать в payload JWT токена хэш хэша пароля?
Собственно, сабж.
Зачем это в принципе - если положить туда только внутренний id пользователя, то при смене пароля токен останется валидным. Хотелось бы чтобы выданные токены при старом пароле "автоматически гасились".
Почему хэш хэша, а не хэш - ну это стремно отдавать даже хэш пароля на всеобщее обозрение. Можно и посолить для верности.
При валидации токена будем проверять не только подпись самого токена, даты экспирации и все такое, но и что хэш хэша совпадает с тем что сейчас в БД.
Поскольку речь идет об инфо-безопасности и криптографии.
Лучше ничего не делать. Алгоритмы которые уже используются доказали свою состоятельность и они самодостаточны.
Они экономны и потребляют минимум мега-флопов вычислительных ресурсов.
Если у вас есть идея или предложение как их улучшить - ее надо рассмотреть с позиции вектора атаки и рассмотреть кейсы когда мы что-то конкретное изменяем и это приводит к устранению этого вектора атаки либо к уменьшению его вероятности.
Если такое доказать нельзя - то и ничего делать не стоит.
mayton2019, с алгоритмами никто не спорит) Речь не об алгоритмах, а о наполнении payload токена. Токен задизайнен так чтобы туда класть разные и произвольные данные и от этого получались разные варианты использования.
Пароль и JWT токен равнозначны. Это Аутентифика́ция пользователя.
И смена одного не должны влиять на другое.
Если вам нужен механизм анулирования JWT токенов, то просто внесите в него элемент сессии.
Например прописывайте RefId, который остается от токена к токену, поку не потребуется его заблокировать.
Можно внести в "черные списки" на максимальное время жизни токена.
И в данном случае если у вас реализован механизм единого входа, вашему паролю не понадобиться выходить за пределы сервиса Аутентификации
vladzen13, Вот появиться у вас механизм "единого входа", т.е. токен выдает сервис Аутентификации, такой как OpenId, а сам токен будет использоваться в других сервисах. И откуда сервисы возьму для проверки кеш пароля?
Да и смысла нет скидывать все активные сессии при обычной плановой смене пароля.
Нужную вам проверку можно реализовать зная только дату выдачи токена.
Если дата выдачи токена меньше, чем дата изменения пароля - тогда считаем токен отозванным.
+ Не всегда следует при смене пароля отзывать все токены.
Для проверки можно передать целиком весь токен в сервис аутентификации.
Простой
Средний
Сложный
