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

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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

Ответ 2

Скрытие соли не нужно.

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Для получения дополнительной информации о перце, проверьте здесь.

См. также hmac.

Ответ 6

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

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

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.

Ответ 7

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

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

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

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

Ответ 8

Существует два метода с разными целями:

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

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

Ответ 9

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

Ответ 10

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

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

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

Marianne2ae85fb5d

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