Необходимость сокрытия соли для приготовления хеша
https://stackoverflow.com/questions/213380
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В работе у нас есть две конкурирующие теории относительно солей.Продукты, над которыми я работаю, используют что-то вроде имени пользователя или номера телефона для соления хэша.По сути, это нечто, что отличается для каждого пользователя, но легко доступно для нас.Другой продукт случайным образом генерирует соль для каждого пользователя и меняется каждый раз, когда пользователь меняет пароль.Затем соль зашифровывается в базе данных.
Мой вопрос в том, действительно ли необходим второй подход?Я могу понять с чисто теоретической точки зрения, что это более безопасно, чем первый подход, но как насчет с точки зрения практичности?Прямо сейчас, чтобы аутентифицировать пользователя, соль должна быть незашифрована и применена к регистрационной информации.
Подумав об этом, я просто не вижу реального усиления безопасности от такого подхода.Изменение соли от учетной записи к учетной записи по-прежнему чрезвычайно затрудняет кому-либо попытку принудительного использования алгоритма хеширования, даже если злоумышленник знал, как быстро определить, что это было для каждой учетной записи.Это делается в предположении, что пароли достаточно надежны.(Очевидно, что найти правильный хэш для набора паролей, где все они состоят из двух цифр, значительно проще, чем найти правильный хэш паролей, состоящих из 8 цифр).Я ошибаюсь в своей логике, или есть что-то, чего мне не хватает?
Редактировать: Итак, вот причина, по которой я думаю, что шифровать соль действительно спорно.(дай мне знать, на правильном ли я пути).
Для следующего объяснения мы предположим, что пароли всегда состоят из 8 символов, а соль равна 5, и все пароли состоят из строчных букв (это просто упрощает математику).
Наличие разной соли для каждой записи означает, что я не могу использовать одну и ту же таблицу rainbow (на самом деле технически я мог бы, если бы у меня была таблица достаточного размера, но давайте пока проигнорируем это).Насколько я понимаю, это настоящий ключ к разгадке, потому что, чтобы взломать каждую учетную запись, мне приходится, так сказать, изобретать велосипед для каждой из них.Теперь, если бы я знал, как применить правильную соль к паролю для генерации хэша, я бы сделал это, потому что соль на самом деле просто увеличивает длину / сложность хэшированной фразы.Таким образом, я бы сократил количество возможных комбинаций, которые мне нужно было бы сгенерировать, чтобы "знать", что у меня есть пароль + соль, с 13 ^ 26 до 8 ^ 26, потому что я знаю, в чем соль.Теперь это облегчает задачу, но все равно очень сложно.
Итак, перейдем к шифрованию соли.Если бы я знал, что соль зашифрована, я бы не стал сначала пытаться расшифровать ее (предполагая, что я знаю, что у нее достаточный уровень шифрования).Я бы проигнорировал это.Вместо того чтобы пытаться выяснить, как его расшифровать, возвращаясь к предыдущему примеру, я бы просто сгенерировал большую радужную таблицу, содержащую все ключи для 13 ^ 26.Незнание соли определенно замедлило бы меня, но я не думаю, что это усложнило бы монументальную задачу - сначала попытаться взломать шифрование с помощью соли.Вот почему я не думаю, что оно того стоит.Мысли?
Вот ссылка, описывающая, как долго пароли будут сохраняться при атаке методом перебора:http://www.lockdown.co.uk/?pg=combi
Решение
Ответ здесь - спросить себя, от чего вы действительно пытаетесь защитить? Если у кого-то есть доступ к вашей базе данных, то у него есть доступ к зашифрованным солям, и они, вероятно, также имеют доступ к вашему коду. Со всем этим они могли расшифровать зашифрованные соли? Если так, то шифрование в любом случае бесполезно. Соль действительно в том, чтобы сделать это таким образом, что невозможно создать радужную таблицу, которая взломает всю вашу базу паролей за один раз, если она будет взломана. С этой точки зрения, до тех пор, пока каждая соль уникальна, нет никакой разницы, для ваших паролей или зашифрованных солей потребуется индивидуальная атака методом грубой силы.
Другие советы
Скрывать соль не нужно.
Для каждого хэша должна использоваться другая соль. На практике этого легко добиться, получив 8 или более байтов от генератора случайных чисел криптографического качества.
<Ч>Соль помогает предотвратить атаки на предварительно вычисленные словари.
Предположим, у злоумышленника есть список вероятных паролей. Он может хэшировать каждого и сравните его с хешем пароля своей жертвы, и посмотрите, Матчи. Если список большой, это может занять много времени. Он не хочу потратить столько времени на следующую цель, поэтому он записывает результат в "словаре" где хеш указывает на соответствующий вход. Если список паролей очень, очень длинный, он может использовать такие методы, как Радужный стол для экономии места.
Однако предположим, что его следующая цель солила свой пароль. Даже если злоумышленник знает, что такое соль, его предварительно вычисленная таблица бесполезный - соль меняет хэш, полученный в результате каждого пароля. Он должен повторно хэшировать все пароли в своем списке, прикрепив соль на вход. Каждая другая соль требует другого словарь, и если будет использовано достаточно солей, злоумышленнику не хватит места хранить словари для них всех. Торгового пространства для экономии времени нет длиннее вариант; злоумышленник должен вернуться к хешированию каждого пароля в своем списке для каждой цели, которую он хочет атаковать.
Итак, не нужно хранить соль в секрете. Обеспечение того, чтобы злоумышленник не имеет предварительно вычисленный словарь, соответствующий этому конкретной соли достаточно.
Подумав об этом немного больше, я понял, что обманывать себя, думая, что соль может быть спрятана, опасно. Гораздо лучше предположить, что соль не может быть спрятана, и спроектировать систему так, чтобы она была безопасной. Я предоставляю более подробное объяснение в другом ответ.
Мое понимание "соли" является то, что это делает взлом более трудным, но он не пытается скрыть дополнительные данные. Если вы пытаетесь повысить безопасность, делая «секрет» «секретным», тогда вам действительно нужно больше битов в ключах шифрования.
Второй подход лишь немного более безопасен.Соли защищают пользователей от атак по словарю и радужных таблиц.Они затрудняют амбициозному злоумышленнику скомпрометировать всю вашу систему, но по-прежнему уязвимы для атак, нацеленных на одного пользователя вашей системы.Если вы используете общедоступную информацию, например номер телефона, и злоумышленник осознает это, тогда вы сэкономили им шаг в их атаке.Конечно, вопрос спорный, если злоумышленник получит всю вашу базу данных, соли и все остальное.
Редактировать: После повторного прочтения этого ответа и некоторых комментариев мне приходит в голову, что некоторая путаница может быть связана с тем фактом, что я сравниваю только два очень конкретных случая, представленных в вопросе:случайная соль противнеслучайная соль.Вопрос о использование телефонного номера в качестве соли является спорным, если злоумышленник получит всю вашу базу данных, нет встает вопрос об использовании соли вообще.
Скрытая соль больше не является солью. Это перец. Это имеет свое применение. Это отличается от соли.
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, то user2 не сможет войти с паролем пользователя 1.
... что-то вроде имени пользователя или номера телефона, чтобы засолить хеш. ...
Мой вопрос: действительно ли необходим второй подход? Я могу понять с чисто теоретической точки зрения, что он более безопасен, чем первый, но как насчет практичности?
С практической точки зрения соль - это деталь реализации. Если вы когда-нибудь измените способ сбора и хранения информации о пользователе & # 8211; и имена пользователей и номера телефонов иногда меняются, чтобы использовать ваши точные примеры & # 8211; тогда вы могли поставить под угрозу свою безопасность. Хотите ли вы, чтобы такое внешнее изменение имело гораздо более серьезные проблемы с безопасностью?
Требует ли отмена требования о том, что у каждой учетной записи есть номер телефона, провести полную проверку безопасности, чтобы убедиться, что вы не открыли эти учетные записи для компрометации безопасности?
Есть два метода, преследующих разные цели:
"Соль" используется для того, чтобы два в остальном одинаковых пароля шифровались по-разному.Таким образом, злоумышленник не сможет эффективно использовать атаку по словарю против всего списка зашифрованных паролей.
(Общий) "секрет" добавляется перед хэшированием сообщения, чтобы злоумышленник не мог создавать свои собственные сообщения и получать их принятие.
Я склонен скрывать соль. Я использую 10 бит соли, добавляя случайное число от 1 до 1024 к началу пароля перед его хэшированием. При сравнении пароля, введенного пользователем с хешем, я делаю цикл от 1 до 1024 и пробую каждое возможное значение соли, пока не найду совпадение. Это занимает менее 1/10 секунды. Я получил идею сделать это таким образом из PHP password_hash и password_verify . В моем примере «стоимость» 10 на 10 бит соли. Или из того, что сказал другой пользователь, скрытый "соль" называется "перец". Соль не зашифрована в базе данных. Это грубое вытеснение. Это сделало бы радужный стол необходимым для обращения хеша в 1000 раз больше. Я использую sha256, потому что это быстро, но все еще считается безопасным.
Действительно, это зависит от того, от какого типа атаки вы пытаетесь защитить свои данные.
Цель уникальной соли для каждого пароля - предотвратить словарную атаку на всю базу паролей.
Шифрование уникальной соли для каждого пароля усложнит взлом отдельного пароля, да, но вы должны взвесить, есть ли какая-то польза от этого. Если злоумышленник с помощью грубой силы обнаружит, что эта строка:
Marianne2ae85fb5d
хэши к хешу, хранящемуся в БД, неужели так сложно понять, какая часть является проходом, а какая - солью?
