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

Мой вопрос: действительно ли необходим второй подход? Я могу понять с чисто теоретической точки зрения, что он более безопасен, чем первый подход, но как быть с практической точки зрения. Прямо сейчас, чтобы аутентифицировать пользователя, соль должна быть незашифрована и применена к информации для входа.

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

РЕДАКТИРОВАТЬ: Хорошо, так вот почему я думаю, что это действительно спорный вопрос, чтобы зашифровать соль. (дай мне знать, если я на правильном пути).

В следующем объяснении мы будем предполагать, что пароли всегда состоят из 8 символов, а соль - 5, а все пароли состоят из строчных букв (это просто упрощает математику).

Наличие разной соли для каждой записи означает, что я не могу использовать одну и ту же радужную таблицу (на самом деле технически я мог бы, если бы у меня был достаточный размер, но давайте пока проигнорируем это). Это реальный ключ к соли из того, что я понимаю, потому что, чтобы взломать каждый аккаунт, я должен заново изобрести колесо, так сказать для каждого. Теперь, если я знаю, как применить правильную соль к паролю для генерации хеша, я бы сделал это, потому что соль действительно просто увеличивает длину / сложность хешированной фразы. Поэтому я бы сократил число возможных комбинаций, которые мне нужно было бы сгенерировать, чтобы «знать», что у меня есть пароль + соль с 13 ^ 26 до 8 ^ 26, потому что я знаю, что такое соль. Теперь это облегчает, но все еще очень сложно.

Так что на шифрование соли. Если бы я знал, что соль зашифрована, я бы не стал сначала пытаться ее расшифровать (если я знаю, что она имеет достаточный уровень шифрования). Я бы проигнорировал это. Вместо того, чтобы пытаться понять, как его расшифровать, возвращаясь к предыдущему примеру, я просто сгенерировал бы большую радужную таблицу, содержащую все ключи для 13 ^ 26. Не зная, что соль определенно замедлит меня, но я не думаю, что это добавит монументальную задачу - сначала попытаться взломать шифрование соли. Вот почему я не думаю, что это того стоит. Мысли?

Вот ссылка, описывающая, как долго пароли будут держаться при атаке методом перебора:http://www.lockdown.co.uk/?pg=combi