Необходимость сокрытия соли для гашиша
на работе у нас есть две конкурирующие теории для соли. Продукты, над которыми я работаю, используют что-то вроде имени пользователя или номера телефона для соли хэша. По сути, то, что отличается для каждого пользователя, но легко доступно для нас. Другой продукт случайным образом генерирует соль для каждого пользователя и изменяется каждый раз, когда пользователь меняет пароль. Затем соль шифруется в базе данных.
мой вопрос в том, действительно ли необходим второй подход? Я могу понять от чисто теоретическая перспектива, что это более безопасно, чем первый подход, но как насчет С точки зрения практичности. Прямо сейчас, чтобы аутентифицировать пользователя, соль должна быть незашифрована и применена к регистрационной информации.
подумав об этом, я просто не вижу реальной выгоды для безопасности от этого подхода. Изменение соли от учетной записи к учетной записи, по-прежнему делает его чрезвычайно трудным для кого-то, чтобы попытаться перебить алгоритм хэширования, даже если злоумышленник был известно, как быстро определить, что это было для каждого счета. Это происходит в предположении, что пароли достаточно сильны. (Очевидно, что найти правильный хэш для набора паролей, где они все две цифры значительно проще, чем найти правильный хэш паролей, которые являются 8 цифр). Я ошибаюсь в своей логике, или есть что-то, что я упускаю?
EDIT: Итак, вот причина, по которой я думаю, что это действительно спорно для шифрования соль. (дай мне знать, если я на правильном пути).
для следующего объяснения мы предположим, что пароли всегда состоят из 8 символов, а соль-из 5, и все пароли состоят из строчных букв (это просто упрощает математику).
наличие другой соли для каждой записи означает, что я не могу использовать одну и ту же радужную таблицу (на самом деле технически я мог бы, если бы у меня был один достаточный размер, но давайте пока проигнорируем это). Это настоящий ключ к соли из того, что я понимаю, потому что, чтобы взломать каждый счет, я должен изобрести колесо, так сказать, для каждого. Теперь, если я знаю, как применить правильную соль к паролю для генерации хэша, я бы сделал это, потому что соль действительно просто расширяет длину/сложность хэшированной фразы. Поэтому я бы сократил количество возможных комбинаций, которые мне нужно было бы создать, чтобы "знать" у меня есть пароль + соль от 13^26 до 8^26, потому что я знаю, что такое соль. Теперь это делает его проще, но все же действительно трудный.
Так на шифрование соли. Если я знаю, что соль зашифрована, я бы не стал пытаться расшифровать ее (предполагая, что у нее достаточный уровень шифрования). Я бы проигнорировал это. Вместо того, чтобы пытаться выяснить, как расшифровать его, возвращаясь к предыдущему примеру, я бы просто сгенерировал большую радужную таблицу, содержащую все ключи для 13^26. Не зная, что соль определенно замедлит меня, но я не думаю, что это добавит монументальную задачу попытаться взломать сначала шифрование соли. Вот почему я не думаю, что это того стоит. Мысли?
вот ссылка, описывающая, как долго пароли будут держаться под атакой грубой силы: http://www.lockdown.co.uk/?pg=combi
10 ответов:
ответ здесь, чтобы спросить себя, что вы действительно пытаетесь защитить от? Если у кого-то есть доступ к вашей базе данных, то у них есть доступ к зашифрованным солям, и они, вероятно, также имеют доступ к вашему коду. Со всем этим они могли бы расшифровать зашифрованные соли? Если это так, то шифрование в значительной степени бесполезно в любом случае. Соль действительно есть, чтобы сделать это так, что невозможно сформировать радужную таблицу, чтобы взломать всю базу данных паролей за один раз, если она будет взломана. С этой точки зрения, пока каждая соль уникальна, нет никакой разницы, потребуется атака грубой силы с вашими солями или зашифрованными солями для каждого пароля индивидуально.
скрывать соль не нужно.
для каждого хэша должна использоваться другая соль. На практике этого легко достичь, получив 8 или более байт от генератора случайных чисел криптографического качества.
соль помогает предотвратить заранее вычисленные атаки словаря.
предположим, что у злоумышленника есть список вероятных паролей. Он может хэш каждого и сравните его с хэшем своего пароль жертвы, и посмотреть, если это спички. Если список большой, это может занять много времени. Он не хотите потратить столько времени на свою следующую цель, чтобы он записал результат в "словаре", где хэш указывает на его соответствующий вход. Если список паролей очень и очень длинный, он может использовать такие методы, как Радужный стол, чтобы сэкономить место.
однако, предположим, что его следующая цель засолила свой пароль. Даже если злоумышленник знает, что такое соль, его предварительно вычисляют таблица бесполезно-соль изменяет хэш, полученный от каждого пароля. Он должен повторно хэшировать все пароли в своем списке, прикрепляя цель соль на вход. Каждая другая соль требует другого словарь, и если используется достаточное количество солей, у злоумышленника не будет места хранить словари для них всех. Торгового пространства для экономии времени нет более длинный вариант; злоумышленник должен вернуться к хэшированию каждого пароля в его списке для каждой цели, которую он хочет атаковать.
таким образом, нет необходимости держать соль в секрете. Обеспечение у злоумышленника нет предварительно вычисленного словаря, соответствующего этому конкретной соли достаточно.
подумав об этом немного больше, я понял, что обманывать себя, думая, что соль может быть скрыта, опасно. Гораздо лучше предположить, что соль не может быть скрыта, и разработать систему, чтобы быть безопасным, несмотря на это. Я предоставляю более подробное объяснение in другой ответ.
мое понимание "соли" заключается в том, что она затрудняет взлом, но не пытается скрыть дополнительные данные. Если вы пытаетесь получить больше безопасности, сделав соль "секретной", то вы действительно просто хотите больше битов в ваших ключах шифрования.
второй подход только немного более безопасен. Соли защищают пользователей от атак словарей и атак радужных таблиц. Они затрудняют амбициозному злоумышленнику компрометировать всю вашу систему, но по-прежнему уязвимы для атак, направленных на одного пользователя вашей системы. Если вы используете общедоступную информацию, например номер телефона,и злоумышленник узнает об этом, то вы сохранили им шаг в их атаке. Конечно же вопрос это спорно, если злоумышленник получает всю вашу базу данных, соли и все.
EDIT: после перечитывания этого ответа и некоторых комментариев мне приходит в голову, что некоторая путаница может быть связана с тем, что я сравниваю только два очень конкретных случая, представленных в вопросе: случайная соль против неслучайной соли. Вопрос о использование телефонного номера в качестве соли спорно, если злоумышленник получает всю вашу базу данных,не вопрос использование соли вообще.
скрытая соль больше не соль. Это Пеппер. Он имеет свое применение. Это отличается от соли.
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 не то же самое salt2 Если Hash2 заменяется на Hash1, то user2 не может войти в систему с помощью пароля users 1.
... что-то вроде имени пользователя или номера телефона, чтобы посолить хэш. ...
мой вопрос в том, действительно ли необходим второй подход? Я могу понять с чисто теоретической точки зрения, что это более безопасно, чем первый подход, но как насчет С точки зрения практичности?
С практической точки зрения, соль-это деталь реализации. Если вы когда – нибудь измените способ сбора или обслуживания информации о пользователе- и имена пользователей и номера телефонов иногда меняются, чтобы использовать ваши точные примеры-тогда вы, возможно, нарушили свою безопасность. Вы хотите, чтобы такое внешнее изменение имело гораздо более глубокие проблемы безопасности?
нужно ли останавливать требование о том, что у каждой учетной записи есть номер телефона, чтобы включить полную проверку безопасности, чтобы убедиться, что вы не открыли эти учетные записи для компромисса безопасности?
есть два метода, с разными целями:
"соль" используется, чтобы сделать два в противном случае равные пароли шифровать по-разному. Таким образом, злоумышленник не может эффективно использовать словарную атаку против целого списка зашифрованных паролей.
(общий) "секрет" добавляется перед хэшированием сообщения, так что злоумышленник не может создавать свои собственные сообщения и принимать их.
Я склонен скрывать соли. Я использую 10 бит соли, добавляя случайное число от 1 до 1024 в начало пароля перед его хэшированием. При сравнении пароля, введенного пользователем с хэшем, я делаю цикл от 1 до 1024 и пробую все возможные значения соли, пока не найду совпадение. Это занимает менее 1/10 секунды. Я получил идею сделать это таким образом из PHP функция password_hash и функцию password_verify. В моем примере "стоимость" составляет 10 за 10 бит соль. Или из того, что сказал другой пользователь, скрытая "соль" называется "перец". Соль не зашифрована в базе данных. Это грубое вытеснение. Это сделало бы радужную таблицу необходимой для обратного хэша в 1000 раз больше. Я использую sha256, потому что это быстро, но все еще считается безопасным.
действительно, это зависит от того, от какого типа атаки вы пытаетесь защитить свои данные.
цель уникальной соли для каждого пароля-предотвратить атаку словаря на всю базу паролей.
шифрование уникальной соли для каждого пароля затруднит взлом отдельного пароля, да, но вы должны взвесить, действительно ли есть большая польза. Если злоумышленник, путем грубой силы, обнаружит, что это строка:
Marianne2ae85fb5dхэши для хэша, хранящегося в БД, действительно ли так сложно выяснить, какая часть является пропуском, а какая-солью?