Необходимость скрывать соль для хеша

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

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

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

EDIT: Хорошо , так вот почему я думаю , что это действительно спорный вопрос , чтобы зашифровать соль. (дай мне знать, на правильном ли я пути).

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

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

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

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

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

Скрывать соль не нужно.

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

Из моего предыдущего ответа :

Соль помогает предотвратить атаки по заранее вычисленному словарю.

Предположим, у злоумышленника есть список вероятных паролей. Он может хешировать каждый и сравнить его с хешем пароля своей жертвы и посмотреть, совпадает ли он. Если список большой, это может занять много времени. Он не хочет тратить так много времени на следующую цель, поэтому записывает результат в «словарь», где хеш указывает на соответствующий вход. Если список паролей очень и очень длинный, он может использовать такие приемы, как радужная таблица, чтобы сэкономить место.

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

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

Поразмыслив над этим еще немного, я понял, что обмануть себя, думая, что соль можно спрятать, опасно. Гораздо лучше предположить, что соль нельзя спрятать, и, несмотря на это, спроектировать систему так, чтобы она была безопасной. Я дам более подробное объяснение в другом ответе.

Однако недавние рекомендации NIST поощряют использование дополнительной секретной «соли» (я видел, как другие называли этот дополнительный секрет «перцем»). Одна дополнительная итерация вывода ключа может быть выполнена с использованием этого секрета в качестве соли. Вместо того, чтобы повышать устойчивость к атаке с предварительно вычисленным поиском, этот раунд защищает от подбора пароля, как и большое количество итераций в хорошей функции получения ключа. Этот секрет не имеет смысла, если хранится с хешированным паролем; он должен храниться в секрете, а это может быть сложно в большой базе данных пользователей.

Я понимаю, что «соль» затрудняет взлом, но не пытается скрыть лишние данные. Если вы пытаетесь повысить безопасность, сделав соль «секретной», то вам действительно нужно больше битов в ваших ключах шифрования.

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

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

... что-то вроде имени пользователя или номера телефона для добавления хэша. ...

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

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

Требуется ли отмена требования о том, что у каждой учетной записи есть номер телефона, включать полную проверку безопасности, чтобы убедиться, что вы не открыли эти учетные записи с точки зрения безопасности?

Скрытая соль больше не соль. Это перец. В нем есть свое применение. Он отличается от соли.

Pepper - это секретный ключ, добавленный к паролю + соли, который превращает хэш в HMAC (код аутентификации сообщений на основе хэша). Хакер, имеющий доступ к выходным данным хэша и соли, теоретически может угадать ввод, который будет генерировать хэш (и, следовательно, пройти проверку в текстовом поле пароля) методом перебора. Добавляя перец, вы увеличиваете проблемное пространство криптографически случайным образом, делая проблему неразрешимой без серьезного оборудования.

Дополнительную информацию о перце можно найти здесь .

См. Также hmac .

Вот простой пример, показывающий, почему плохо иметь одну и ту же соль для каждого хэша.

Рассмотрим следующую таблицу

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

Случай 1, когда соль 1 совпадает с солью 2 Если Hash2 заменяется на Hash1, то пользователь 2 может войти в систему с паролем пользователя 1

Случай 2, когда соль 1 не совпадает с солью 2. Если Hash2 заменен на Hash1, то пользователь 2 не может войти в систему с паролем пользователя 1.

Есть две техники с разными целями:

• «Соль» используется для того, чтобы два одинаковых пароля шифровались по-разному. Таким образом, злоумышленник не может эффективно использовать словарную атаку против всего списка зашифрованных паролей.

• (Общий) «секрет» добавляется перед хешированием сообщения, чтобы злоумышленник не мог создавать свои собственные сообщения и принимать их.

Я стараюсь скрыть соль. Я использую 10 бит соли, добавляя случайное число от 1 до 1024 в начало пароля перед его хешированием. Сравнивая пароль, введенный пользователем, с хешем, я перебираю от 1 до 1024 и пробую все возможные значения соли, пока не найду совпадение. Это занимает менее 1/10 секунды. Мне пришла в голову идея сделать это таким образом из файлов PHP password_hash и password_verify . В моем примере «стоимость» равна 10 за 10 кусочков соли. Или, как сказал другой пользователь, скрытая «соль» называется «перцем». В базе данных соль не зашифрована. Это грубое вытеснение. Это сделало бы радужную таблицу необходимой, чтобы перевернуть хэш в 1000 раз больше. Я использую sha256, потому что он быстрый, но все же считается безопасным.

На самом деле, это зависит от того, от какого типа атаки вы пытаетесь защитить свои данные.

Назначение уникальной соли для каждого пароля - предотвратить словарную атаку на всю базу паролей.

Да, шифрование уникальной соли для каждого пароля затруднит взлом индивидуального пароля, но вы должны взвесить, действительно ли это дает большую пользу. Если злоумышленник методом грубой силы обнаружит, что эта строка:

Marianne2ae85fb5d

хеши к хешу, хранящемуся в БД, неужели так сложно понять, какая часть является проходом, а какая - солью?