Каков наилучший способ засолки и хранения соли?

Question

Привет, ребята, я читал о подмене пароля, но это может звучать немного странно. Но как мне хранить и хранить соль. Например, в архитектуре с несколькими шинами говорят, что я использую GUID клиентского компьютера для генерации моей соли, тогда пользователь ограничивается одной машиной, но если я использую случайную соль, она должна где-то храниться. Несколько дней назад я видел пример приложения, в котором хеш и соль генерировались в клиентской системе всякий раз, когда создавался новый пользователь, а затем соленый пароль и хеш передавались на сервер, где они хранятся на сервере SQL. Но если я буду следовать этому методу, и база данных будет скомпрометирована, пароли и значения соли для каждого пароля будут доступны для X. Итак, я должен снова засолить / зашифровать пароли и получить соль на стороне сервера? Какова лучшая практика посола?

Answer 1

Хранение соли в незашифрованном виде в базе данных рядом с хешированными паролями не является проблемой.

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

См. отличный пост на эту тему Томаса Птачека.

edit @ ZJR : даже если бы соли были полностью публичными, они все равно потеряли бы преимущество радужных таблиц. Когда у вас есть соленые и хешированные данные, лучшее, что вы можете сделать, чтобы обратить их, - это грубая сила (при условии, что хеш-функция криптографически безопасна)

edit @ n10i : См. Статью в Википедии о безопасной хэш-функции . Что касается размера соли, популярная реализация bcrypt .gensalt () использует 128 бит.

Answer 2

Пожалуйста, найдите время, чтобы прочитать это очень хорошее описание солей и перемешивания

Программное обеспечение для генерации соли и с открытым исходным кодом