Оставим за скобками то, что масштабирование ipc уже вызывает вопросы
Смена типа сокета происходит изменением одной строки, собственно адреса, который слушает сервер
Я всё таки думаю, что люди просто не знают про такую возможность
По крайней мере у меня в практике было именно так, люди, использующие наше api спрашивали что за странные строчки такие, которые надо слушать

Приет ребята. У меня вопрос касательно bcrypt’a и хранения солей с паролями. Как лучше всего хранить эти самые пароли с солями? Понятно, если у меня одна соль для всех юзеров, то я храню в .env файле, но если я хочу соль для каждого юзера, то по логике соль мне надо хранить вместе с паролем в одной базе? Есть ли способ понадёжней этого?

ну храни в разных базах =) а вообще, смотря чего ты опасаешься, если взлома сервака всего - то пофигу как и где ты их будешь хранить, а если речь исключительно про вероятность "сперли базу", то можно пойти более хитрым способом, в качестве соли использовать некий хеш, который генеришь на основании других полей по определенному правилу [например md5(логин+мыло+дата регистрации)] - и все, если уперли только базу, а код не получили, то не ная алгоритма формирования соли ее не смогут получить

Либо шифровать генерировать соль и шифровать её еще каким-то способом и соль от соли уже хранить на серваке 🙂 Но твой способ тоже интересный, спасибо)

если совсем параноя, тогда добавляем к формированию "виртуальной соли" (на базе статичных полей) динамическое поле, последней авторизации и работаем по принципу:
- человек автризуется (пароль бек получает в явном виде)

- по текущим данным в БД проверяется правильность
- если все верно, то генерим значение для поля "последняя авторизация"
- генерим новую соль на основе статичных полей и нового значения
- и перезаписываем хеш пароля + поле "последняя авторизация"

и получаем постоянно изменяемый хеш при каждой авторизации пользователя

так что кража базы вообще ничего не даст (если не знать алгоритм генерации соли на базе полей юзера)

Интересный подход, взломать будет трудно, но я подозреваю хакеры уже многого навидались и этот подход не очень читабелен, но я думаю потратив какое-то колво времени можно и это вскрыть

Но это будут проблематично, согласен)

хакера уже базы не сильно вскрывают - проще нужного юзера ломануть =)))

или просто продать базу мыльников

ну добавь еще и соль-на-соль через env =))) строй многоступенчатое хеширование =)))

А потом сервак просто ляжет на минимальном брутфорсе )

Всем салют.
Чет я туплю - как в seqlize  выбрать все сто создано сегодня? (по полю createdAt) - там дата со временем до секунды сохраняется...

Попробуй дату без времени в условие вписать

а почему хранить соль рядом с хэшем ненадёжно?

Хмм

Впринципе да, в bcrypt нету же обратной расшифровки. Я что-то об этом не подумал

Соли логином/мылом да и всё

дайте сайт c bcrypt шифровкой я вам его за 10 минут разберу

вы такие наивные с этим bcrypt