А теперь сравним подходы: С одной стороны старый добрый проверенный подход,

у которого из минусов - необходимость дополнительной таблицы.

С другой стороны - подход с JWT токенами, в котором проблема может вылезти где угодно (1. утечка jwt токена; 2. переиспользование ссылки сброса пароля с действующим jwt; 3. использование jwt токена как токена для сессии; и это варианты, которые первыми пришли в голову за 10 минут). Где из преимуществ только отсутствие еще одной таблицы в БД.

Как думаешь, какой вариант выберет безопасник?)

Так ставишь время жизни аксеса 1 мин и норм

А если вместо токена будет скуля? Тогда жвт будет лучше, так как токен жвт в файле, а не в базе (обычно)

Usability становится не оч. Мне приходит линк, пока я открою почту, пока найду письмо в спаме, пока по нему кликну + потенциальные задержки на стороне отправки письма

тебе чтобы воткнуть в токен скулю, для начала нужно приватный ключ найти

А в чем тут проблема с безой?

Я не про модификацию жвт, я про обычный токен, который хранится в базе и при клике потом удаляется

Тебе бизнес скажет "нет"

А вдруг там будет RCE?

Это как-то связано с жизнью токена? Мы сейсас в целом про jwt или про сброс пароля?

Вот именно. Если бы да кабы да во рту росли грибы 🤓

Я так и не понял, про какую утечку jwt токена ты говоришь. Да и почти все проблемы, которые ты сказал, связаны с неправильной реализацией работы с jwt токеном

JWT генерируется через секретный ключ бекенда, как и любой криптоспособ

Ну если ты украл секреты, то тут проблема не с jwt

Кража секретов считают как вектор атаки тоже

Да, но это не проблема с jwt

Это проблема любого криптоспособа vs БД

Чтобы произошла утечка, нужно взломать бэк, либо брутить. Я как-то брутил jwt, было очень весело. С использованием 9 очень мощных карт, ключ из 10 символов с верхним, нижним регистором спец символами и цифрами - уходило пару лет. А ключ на бэке состоял из 16 символов. + хэшкат больше 10 символов не умеет брутить jwt.

Ну либо ключи хранят в файликe .env рядом

Брут понятно что невозможен, если секрет не 1234. в этом и весь смысл криптографии.

https://example.com/passwordRecover?key=JWT_KEY Подобный запрос логгируется 1) В браузере пользователя 2) На серверной стороне всякими nginx'ами etc.

Про jwt в сбросе пароля. Имхо, использование JWT в приложении нормальная тема, но разрабы все равно допускают некоторые неточности: - хранение токена в localStorage - хранение слишком большой информации в токене - путают refresh токены с access токенами - etc

у меня задача была подтвердить почту, а не сбросить пароль ( до сброса пароля я ещё не дошёл 😂 )

Так останется любой токен, а не только JWT

Только JWT будет жить, пока он не станет expired. А в нормальной реализации на бекенде обычный токен сразу инвалидируетс я

тут суть в том, что любой другой токен инвалидировать можно

У JWT есть экспаеры, это его главная фича

Уф, прошу прощения, зря быканул получается