md5 в частности и хэширование вообще

ilkz

Новичок
md5 в частности и хэширование вообще

Всем привет!
Я вот тут неоднократно наблюдаю различные дискуссии о хранении паролей и прочей приватной юзерской информации. Все почти в один голос используют однонаправленное хэширование, типа md5. Не буду спорить - вещь действительно отличная. Сам ее использую.

Однако, меня совершенно веселит, когда начинают придумывать извраты типа md5(md5(md5($password))) и им подобные замуты.

Ведь это же не панацея. И защищенность десятка md5 относительно вероятности вскрытия ничуть не больше одного md5. Md5 обладает свойством коллизий (т.е. две разные строки могут дать один и тот же хэш). Таким образом, теоретически, что десяток вложенных md5'тей, что всего лишь один md5 могут дать один хэш.

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

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

Гравицапа

elbirret elcno
md5(md5($pass))...
Ну тут по крайней мере один плюс.
Хэши обычно брутофорсятся, то есть перебираются по словарю уже известных пар строка-хэш.
Так вот вероятность найти пару пароль-хэш больше, чем пароль-двойной хэш, потому как базы в основном по
удобным для человека паролям, а не по хэш-хэш.
Если я не прав в своих рассуждениях, то поправьте меня.
 

ilkz

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

И я говорю не только об md5, а о методах хэширования вообще.

-~{}~ 07.02.07 10:33:

В принципе, посчитать 32! (факториал) комбинаций не так уж и напряжно, учитывая то, что сейчас существуют кластерные сети, созданные специально для таких работ.

Более того, что мешает тупо сгенерить таблицу пар ХЭШ=СТРОКА, а в дальнейшем искать не по строке, а по хэшу.

Это будет вообще почти мгновенно. Основная сложность - сгенерить эти миллиарды комбинаций.
 

jonjonson

Охренеть
Я бы скорее вёл речь о СТАНДАРТЕ хранения паролей...

Разного рода "свои" подходы, а их в принципе не так много часто усложняют жизнь при "доработке" сервиса (переделка практически с нуля с сохранением но изменением структуры информации; перенос на другую CMS; объединение пересекающихся по пользователям сервисов).

Я задумывался об универсальном стандарте и его поддержке, но понял одно, что врядле возможно заставить ему следовать. Даже если стандарт будет 100% оптимальным с точки зрения безопасности и лёгкости использования, найдётся куча "идущих своим путём". :)
 

ilkz

Новичок
Автор оригинала: Tor
для обсуждения хешей надо бы выучить названия чисел побольше

вроде 2.6*10^35
Именно. Калькулятором умеешь пользоваться :)
А уж коли пошла такая пьянка - ну тогда скажи как называется число 35 степени десятки?
 

phprus

Moderator
Команда форума
ilkz
В принципе, посчитать 32! (факториал) комбинаций не так уж и напряжно
Даже на кластере полный перебор может занять миллиарды лет. 32! ~= 2,63*10^35 Даже если перебирать 10^20 комбинаций в секунду (а это нереально) то перебор займет примерно 83 438 241 лет.

Более того, что мешает тупо сгенерить таблицу пар ХЭШ=СТРОКА, а в дальнейшем искать не по строке, а по хэшу.
Такого объема памяти просто не существует в природе. Так как требуемый объем не менее чем 1196580510321353040886688,2324219 терабайт. (Для сравнения весь индекс гугла занимает всего каких то 800 терабайт)

P.S. Надеюсь не ошибся в расчетах.
 

Alexandre

PHPПенсионер
Если я не прав в своих рассуждениях, то поправьте меня.
Гравицапа если я имею БД подбора пороля по md5(), то что мне мешает добавить еще поле md5(md5(...)) и тд. ?

Для того, чтоб использовать более защищенное хеширование, то используй алгоритмы sh1, sh256 или sh512

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

Гравицапа

elbirret elcno
Я имел в виду, что
1. базы по хешам идут в основном по понятным человеку паролям
Пример,
sex = 3c3662bcb661d6de679c636744c66b62
2. md5(md5('sex')) = dd00ab580ea6869cd7f7c155a9895665
То есть, для начала надо будет найти соответсвие
dd00ab580ea6869cd7f7c155a9895665 = 3c3662bcb661d6de679c636744c66b62
А это уже достаточно сложно.
равицапа если я имею БД подбора пороля по md5(), то что мне мешает добавить еще поле md5(md5(...))
Куда добавить?
Поиск в базе вроде как идёт по хэшу
Пример, у нас есть
хэш 3c3662bcb661d6de679c636744c66b62 и надо найти пароль
Ищем в базе пароль с таким хэшем.
 

Tor

Новичок
Alexandre
Гравицапа
сообщение phprus читали?
1) если да, прочитайте еще раз
2) если нет, прочитайте и переходите к п.1
 

legend

Новичок
ilkz

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

Ну, первое, разница все-таки есть...
А пользоваться или нет каждый сам решает. Некоторые вообще хешей не используют и живут же..
Другие используют свои "изобретения". Мне, например, вполне хватает md5, но это пока... Все зависит от стоящих перед тобой задач.
 

phprus

Moderator
Команда форума
Гравицапа
Базу данных для хранения md5 которые соответствуют каким либо строкам создать невозможно, так как она будет занимать объем не менее чем 1196580510321353040886688 (10^24) террабайт или 10^36 байт. Для сравнения во всей вселенной всего 10^67 атомов.

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

phprus

Moderator
Команда форума
Гравицапа
Однако если применять md5(md5(пароль)) то никакие бызы не помогут, так как база всех 32 символьнах комбинаций будет записать столкьо сколько я написал в предыдущем сообщении. А после того как мы расшифруем первый md5 нам примедстя расшифровывать второй md5 а это уже делает задачу практически невыполнимой.
 
Сверху