Труднее ли взломать обрезанные хэши? - PullRequest
3 голосов
/ 07 декабря 2011

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

Ответы [ 4 ]

7 голосов
/ 07 декабря 2011

Возьмите эту идею до крайности: предположите, что вы храните только первый шестнадцатеричный символ ваших хешированных паролей.

Все пароли ваших пользователей будут хэшироватьсяв одно из шестнадцати значений:

0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

Я признаю, что John The Ripper будет очень сложно декодировать эти пароли методом перебора, но это также позволяет кому-то угадать пароль другого пользователя в среднем за восемь попыток.

Упс.

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

5 голосов
/ 07 декабря 2011

Краткое резюме того, что я разместил в комментариях выше:

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

В другихслова: Нет, обрезанный хеш не будет более безопасным и фактически будет значительно менее безопасным.Единственное значение будет усложнять злоумышленнику, который «решит» ваш хеш, использование результатов в другой системе.Однако они могли бы прекрасно использовать результаты в вашей системе.

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

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

Например:

Еслизлоумышленник обнаруживает, что a6shp и ghsa2 и apple все уменьшаются до одного и того же обрезанного хэша, затем 1) они смогут войти в вашу систему в ту минуту, когда они столкнулись с первым рабочим результатом, нотакже 2) у них будет довольно хорошая идея, результатом которой был фактически пароль.Если вы обрежете так много данных, что буквально десятки тысяч комбинаций будут совпадать, тогда это станет сложнее (но не на столько на сложнее), и все же безопасность вашей собственной системы теперь существенно снизится.Это продолжается и продолжается до тех пор, пока число столкновений не приблизится к бесконечности.

4 голосов
/ 07 декабря 2011

Обрезка ваших хешей - ДЕЙСТВИТЕЛЬНО ПЛОХАЯ ИДЕЯ.

Рассмотрим следующие два пароля:

password1
password2

Со следующими хешами:

732654732854235
732654732837454

Теперь давайте обрежем эти хэши, чтобы сказать 10 символов. Теперь мы получаем:

7326547328
7326547328

Ух ты, что отстой.

Теперь я могу войти с паролем1 или паролем 2.

Если вы беспокоитесь, что злоумышленник получит базу данных с вашими паролями, просто убедитесь, что вы:

  • использованный склеп
  • использовали уникальные соли для каждого пароля
0 голосов
/ 13 декабря 2018

Непонятно, как определяется «обрезка» хэшей, но я вижу в этом 4 цели:

  1. Хранение данных. Каждое представление, «обрезанное», сохраняет его хранение, увеличивая при этом коллизию.

  2. Ноль знаний (из которых - пароль). (Читайте: молчать время от времени, когда стоит молчать.) Верификатор знает, что:

    1. F ( input ) is hash
    2. F ( ответ ) это хеш
    3. F ( неправильный ответ ) не хэш
    4. F ( ответ 2 ) хеш

    . Но он не знает, является ли ввод ответом или ответом-2. (Читайте: не пытайтесь выдавать себя за Верификатора или зарезервировать / ухаживать за Верификатором, чтобы определить, является ли ввод <атака на рассвете>. <Атака в полдень> хэширует тот же результат. полдень>, <сон на рассвете>, <сон в полдень> все хэши с одинаковым результатом.)

  3. [кстати, это может быть использовано неправильно, поэтому я опускаю это]

  4. [кстати, это может быть использовано неправильно, поэтому я опускаю это]
...