Использование хеша данных как соли

Question

Мне было интересно - есть ли недостатки в использовании хеша чего-либо как соли самого себя?

например. hashAlgorithm (data + hashAlgorithm (data))

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

Мысли? (У меня есть ощущение, что это плохо, но я хотел проверить, действительно ли это так, и если да, то почему.)

Answer 1

Использование хеша данных в качестве соли для данных является не безопасным.

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

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

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

Помните, соль не должна быть секретной, но она не может быть функцией данных, которые солят.

Answer 2

Если у злоумышленника нет доступа к исходному коду

Это называется " безопасность через неизвестность ", что всегда считается плохим. Безопасный по своей природе метод всегда лучше, даже если единственная разница заключается в том, что вы не чувствуете себя спасенным «потому что они не знают как». Кто-то может и всегда найдет алгоритм - с помощью тщательного анализа, методом проб и ошибок, или потому что он нашел источник с помощью SSH-доступа к вашей службе общего хостинга или любым из ста других методов.

Answer 3

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

Answer 4

Это предлагает улучшения по сравнению с простым хэшированием . Используйте случайно сгенерированную соль.

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

Рассмотрим:

data = "test"
hash = hash ("test" + hash ("test"))

Хеш будет постоянным всякий раз, когда data = "test". Таким образом, если у атакующего есть алгоритм (а у атакующего всегда есть алгоритм), он может предварительно рассчитать значения хеш-функции для словаря записей данных.

Answer 5

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

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