Я читал о солении паролей, но это может показаться немного странным. Но как мне хранить и обезопасить соль. Например, в архитектуре с несколькими шинами я использую GUID клиентской машины для создания своей соли, тогда пользователь ограничивается одной машиной, но если я использую случайную соль, ее нужно где-то хранить. Несколько дней назад я видел пример приложения, в котором хеш и соль генерировались в клиентской системе всякий раз, когда создавался новый пользователь, а затем сольный пароль и хэш передаются на сервер, где они хранятся на сервере SQL. Но если я буду следовать этому методу и база данных будет скомпрометирована, пароли и значения соли для каждого пароля будут доступны человеку X. Итак, должен ли я снова солить/шифровать пароли и полученную соль на стороне сервера? Как лучше солить?
Как лучше засолить и хранить соль?
Ответы (2)
Хранение соли в незашифрованном виде в базе данных рядом с хешированными паролями не является проблемой.
Цель соли не быть тайной. Его цель состоит в том, чтобы быть разными для каждого хэша (то есть случайным) и достаточно длинным, чтобы отказаться от использования радужных таблиц. когда злоумышленник получает доступ к базе данных.
См. это отличный пост на эту тему от Томаса Птачека.
отредактируйте @ZJR: даже если бы соли были общедоступными, они все равно лишили бы преимущества радужных таблиц. Когда у вас есть соль и хешированные данные, лучшее, что вы можете сделать, чтобы отменить это, — это грубая сила (при условии, что хеш-функция криптографически безопасна).
редактировать @n10i: См. статью в Википедии для безопасной хеш-функции. Что касается размера соли, популярная реализация bcrypt.gensalt() использует 128 бит.
Пожалуйста, найдите минутку, чтобы прочитать это очень хорошее описание солей и хеширования.
Salt Generation и программное обеспечение с открытым исходным кодом
