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

97
задан ErikE 23 September 2010 в 04:42
поделиться

7 ответов

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

45
ответ дан Vinko Vrsalovic 24 November 2019 в 05:28
поделиться

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

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

От предыдущий мой ответ :

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

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

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

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

<час>

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

97
ответ дан Liam 24 November 2019 в 05:28
поделиться

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

3
ответ дан gbarry 24 November 2019 в 05:28
поделиться

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

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

3
ответ дан Bill the Lizard 24 November 2019 в 05:28
поделиться

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

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

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

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

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

2
ответ дан Charles Faiga 24 November 2019 в 05:28
поделиться

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

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

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

1
ответ дан Patrick McElhaney 24 November 2019 в 05:28
поделиться

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

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

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

Marianne2ae85fb5d

хеши к хешу, сохраненному в DB, он действительно, что трудно для выяснения, что, какая часть является передачей и какая часть является солью?

-1
ответ дан Lucas Oman 24 November 2019 в 05:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: