Зачем хранить соль в базе и как ее использовать?

Да, именно этот пакет я и использую. Т.е. с ним нет смысла хранить соль?

hckn, нет смысла. Во всяком случае можете проверить, если без отдельного задания соли будет работать функция проверки хэша (возвращать true на правильном пароле и false на неправильном) - то отдельно задавать соль бессмысленно.

Т.е. для каждого юзера, перед созданием хеша, выбирать рандомную соль, например в диапазоне 10-16 для bcrypt, и сохранять это значение рядом с самим хешем, и потом при compare также доставать это же значение соли и его использовать?

Ок. А теперь допустим что есть необходимость в смене значения соли. Что дальше? Хеш-то у меня по проежнему старый, а значит при следующем логине юзера мне надо будет опять сравнивнивать правильность ввода пароля со старым хешем (со старой солью). Получается, при последующем логине мне надо выполнить хеш 2 раза - со старой солью, чтобы проверить правильность пароля, а потом згенерировать новый хеш с новой солью? Ппц, это гемор) Я праавильно понял принцип, или надо/можно по другому?

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

А менять значение соли для уже сгенерированного хэша - не вижу случаев, когда это может понадобиться. При утечке хэшей для каждого солёного хэша подбирать пароль придётся всё равно индивидуально (в отличие от несолёных хэшей, которые можно подобрать для всех сразу) - потому разницы никакой не будет, какая именно соль там, важно только, чтобы они были достаточно случайными и не повторялись (но и если случайно повторится 2-3 соли - это не смертельно, просто злоумышленник эти конкретные 2-3 пароля сможет подбирать вместе, что чуточку ему облегчит задачу, но не сильно). А если хэш утёк, то поможет разве что смена самого пароля, а не соли (к тому моменту, как злоумышленник вычислит старый, если ему хватит на это вычислительной мощности - этот пароль уже не будет подходить).

почитай документацию

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

bcrypt.hash автоматом генерирует соль и пихает все в одну строку
https://rmcreative.ru/blog/post/sostavnye-chasti-k...

А теперь допустим что есть необходимость в смене значения соли.

Зачем ?

например в диапазоне 10-16

фишка bcrypt - быть медленным

const saltRounds = 10;
это сложность вычисления

поставив 15, у тебя займет 3 секунды генерация и когда 10 юзеров решать одновременно зайти на твой сайт - у тебя все нормально так подвиснет

rounds=8 : ~40 hashes/sec
rounds=9 : ~20 hashes/sec
rounds=10: ~10 hashes/sec
rounds=11: ~5  hashes/sec
rounds=12: 2-3 hashes/sec
rounds=13: ~1 sec/hash
rounds=14: ~1.5 sec/hash
rounds=15: ~3 sec/hash
rounds=25: ~1 hour/hash
rounds=31: 2-3 days/hash

planc,

bcrypt.hash автоматом генерирует соль

Это если не указал. Я например, указал

await bcrypt.hash(password, 14.5)

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

А если bcrypt рандомно выбирает соль, то откуда он знает какое значение использовать при последующем compare? Этого всего в документации npm пакета нету! Вероятнотно надо читать спецификацию самого принципа шифрования, но это наверное перебор в моем случае, хотя тема интересная.

Вообщем мораль - не надо хранить соль?