A
Вроде нашёл решение - https://stackoverflow.com/a/51001564
Size: a a a
2019 October 29
RK
Народ, а кто подскажет, в JWT-токене обязательно/желательно ли в payload-e передавать username? Или достаточно будет userId, iat и exp?
z
Так вот прикол в том, что даже если и взломали, то у всех разная соль, и для каждой записи нужно свою радужную генерить, а это накладно
до меня только что дошло (надеюсь что правильно), то что в бд будет лежать:
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
И
Народ, а кто подскажет, в JWT-токене обязательно/желательно ли в payload-e передавать username? Или достаточно будет userId, iat и exp?
что угодно
но по спефикации вроде как sub поле для этого отведено
но по спефикации вроде как sub поле для этого отведено
RK
до меня только что дошло (надеюсь что правильно), то что в бд будет лежать:
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
да-да, именно первый вариант, как вы и написали
RK
что угодно
но по спефикации вроде как sub поле для этого отведено
но по спефикации вроде как sub поле для этого отведено
ну в sub у меня айдишник юзера и лежит
A
до меня только что дошло (надеюсь что правильно), то что в бд будет лежать:
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
соль + хэш(соль+пароль)
, до этого у меня было представление что это лежит в бд так :
соль + хэш(пароль)
Вообщем спасибо большое за помощь🤝
в случае bcrypt будет лежать только хэш(соль+пароль)
И
ну в sub у меня айдишник юзера и лежит
этого вполне достаточно для идентификации
z
в случае bcrypt будет лежать только хэш(соль+пароль)
да кстати, это круто.
Но теперь вопрос, как он сравнивает хэш, если у него нету той соли при которой он хэшировал?😑
Но теперь вопрос, как он сравнивает хэш, если у него нету той соли при которой он хэшировал?😑
RK
в случае bcrypt будет лежать только хэш(соль+пароль)
я с bcrypt не сталкивался, к сожалению пока, но у каждого же пользователя предполагается разная соль, где её тогда хранить, как не в базе? или там как-то по другому это устроено?
RK
да кстати, это круто.
Но теперь вопрос, как он сравнивает хэш, если у него нету той соли при которой он хэшировал?😑
Но теперь вопрос, как он сравнивает хэш, если у него нету той соли при которой он хэшировал?😑
вот вот, и я про это
z
я с bcrypt не сталкивался, к сожалению пока, но у каждого же пользователя предполагается разная соль, где её тогда хранить, как не в базе? или там как-то по другому это устроено?
там ее вообще хранить нигде не надо, он хэширует с солью, а конда сравниваешь достаточно только пароля
RK
этого вполне достаточно для идентификации
Спасибо Илья! Понял и уже выпилил пользователя )
RK
там ее вообще хранить нигде не надо, он хэширует с солью, а конда сравниваешь достаточно только пароля
блин, ну чудес же не бывает, если у каждого разная соль, где бкрипт её берёт, чёт не врублюсь.. нада погуглить в яндексе ))
A
я вас запутал -
z
блин, ну чудес же не бывает, если у каждого разная соль, где бкрипт её берёт, чёт не врублюсь.. нада погуглить в яндексе ))
A
bcrypt по дефолту хранит данные в формате 'соль''хеш'
то есть как правило первые несколько бит это соль
то есть как правило первые несколько бит это соль
RK
ах вон оно как.. )
A
то есть метод compare
берет введенный пароль, берет первые 16 бит из записи в базе, солит и сверяет с оставшимися битами(хешем)
берет введенный пароль, берет первые 16 бит из записи в базе, солит и сверяет с оставшимися битами(хешем)