В общем это мне пришло в голову еще давно, но только сейчас я решил это выложить, а точнее спросить, будет ли это эффективнее. Лучше всего объяснять на примере, поэтому я его покажу. Есть простенький скрипт регистрации - авторизации. Регистрируется пользователь с паролем 123456. Современные обычные (без соли) движки заносят в БД md5 хеш пароля, то есть e10adc3949ba59abbe56e057f20f883e. Дальше, когда пользователя авторизируется, md5 хеш введенного пароля сопоставляется с md5 хешем в базе, и если они равны, то авторизация проходит удачно. Так вот, если же сделать алгоритм, который бы заносил не весь хеш, а затирал некие символы, т.е. заносил бы, например e10a*c394*ba59a*be56e057*20f8*3e. При авторизации, скрипт разделяет хеш пароля точно так же и сопоставляет его с хешем в базе. Если затереть всего один символ вероятность распознавания пароля становится уже в 16 раз! ниже. А если затереть пять , то соответственно, вероятность становится в 16*5 = 80 раз ниже. В этом алгоритме также есть и свои недостатки - коллизии. НО вероятность коллизии все равно очень мала, даже при затёртых 5 символах. В общем вот, что вы об этом думаете?
Атака по неполному хэшу решает процесс перебора это раз. Второе, никто не мешает сгенерировать все возможные хэши по маске и брутить уже пачку хэшей. Даже если какой-то совпадёт по маске, велика вероятность что это не коллизия а именно искомый хэш. Идея имеет право на жизнь, но для опытного хэшкрякера не является особым препятсвием для брута неполного хэша. Вероятность подбора пароля не падает, а как раз увеличивается, раз сужается область значений хэшфункции, т.е. ситуация коллизии нас при этом устроит. Единственная защита это соль + более медленный алгоритм хэширования, что и используется, к примнеру md5(unix) отчасти решает проблему защиты пароля от прямого перебора из-за своей медлительности, но по словарю атака остаётся актуальной (точнее даже сказать так можно, что только по словарю актуальны, остальные атаки очень затратны по времени.)
Как именно? Да, но при переборе 80 хешей, скорость будет меньше, чем при 1. Наверное, но прогнать по сервисам хэшкрякинга такой хэш пока невозможно. Но вероятность коллизии небольшая.
Зачем эти заморочки, если есть алгоритмы которые задолбааешься брутить? mailbrush ты пытаешься создать свой устойчивый к бруту алгоритм? Тогда направление не вполне верное ИМХО
Я ничего не пытаюсь сделать, я просто спрашиваю, будет ли устойчивым это от брута. Точнее, не устойчивым, а устойчивее, чем обычный md5.
$name = 'mailbrush'; $pass = 'mailbrush123'; $rand = rand(1000,9999); $hash = md5(md5($name).md5($pass).base64_encode($rand)); и как бы всё
- EGB и Passwords про не почувсвуют разницы при бруте прямым перебором, по словарям, гибридной и комбинированной атакой. - щас нельзя (из-за нагрузки на мускул при поиске), раньше было можно (пункт Атака по маске) - вероятность коллизии увеличивается с каждым вычеркнутым символом, большая не большая эти понятия тут нет смысла использовать ибо всё относительно. Смысл в том что случай коллизии нас так же устроит, как и подбор целевого хэша.
Все значения исходные надо хранить в базе, в том числе и $rand. Что касается брута, то брутить можно будет комбинированной атакой, либо по маске, предварительно подготовля три словарика, где первый словарь - md5($name), второй любой, третий base64_encode($rand)
Пришёл всемирный облом этой идее... А если взять два хеш пароля - один обычный md5, а другой - md5 в этом алгоритме, то какой быстрее расшифруется?
Скорость брута у EGB на моей видухе: 1 хеш = ~450 Милионов пассов в секунду 450 000хешей = ~150-200 Милионов пассов в секунду Думаете шанс коллизии так уж мал?
чем больше доп хэширования, тем конечно медленнее идёт перебор (а не расшифровка). Что как раз сделано в md5(unix) - 1000 циклов солёного md5 каждый раз с разной солью. Что скорость перебора резко уменьшает ~ в 1000 раз на 1 хэше и пропорционально колличеству одновременно перебираемых.
А если такое решение PHP: <?php $l='login';//логин $p='pass';//Пасс $l=md5(sha1($l).sha1($p)); $p=md5(sha1($p).sha1($l)); //тоесть для бруто придётся узнать ещё и логин ?>
Вы не поверите но логины хранятся в той же БД что и пароль с солью Мне больше нравится мысль запихивать в хеш 2 соли, вот это точно неслабо сократит время брута...
Мы тут обсуждаем хранение паролей пользователей, а не админа сайта. Само собой для админа можно сделать любой алгоритм хеширования(даже тройной MD5(Unix)), но вот пассы пользователей так хранить нельзя, ибо нагрузка на сервер будет слишком большой. Вот и ищется компромисс между нагрузкой и криптоустойчивостью...
для того, чтобы защитить конкретный сайт - достаточно ввести на форуме фиксированную 20-символьную соль, которая не хранится в базе, и солить ей все хэши. Тогда, пока злоумышленник не подберет эту соль - а хорошую 20символьную соль он не подберет никогда, или же не получит доступа к сурсам - ни 1 хэш он вскрыть не сможет. ну а если говорить об изобретении "нового криптоустойчивого алгоритма" в целом - то это писец. Собственно в данном случае сложность - не в том, чтобы сделать небрутабельный алгоритм, а в том, чтобы сделать соотношение скорость/криптоустойчивость более высоким, чем у аналогов. Математики такие алгоритмы годами разрабатывают... Да и в любом случае, если известен алгоритм - значит можно будет и атаковать по словарю. От этого не защитишься. Ну а от атак иными, чем словарь методами - вполне защищают и многие уже существующие аналоги
Вот только если он не первый раз этим занимается, он незабудет перед тем как сливать базу зарегить акк с пассом 123456, и тогда узнать такой алгоритм будет не слишком сложно. А вот исключение символов родит коллизии... Мне кажется что лучшей защитой является простая нестандартная комбинация стандартных методов хеширования. Т.е. без доступа к исходникам определить её не просто, а так-же даже при её определении придётся самому писать модули для брута таких хешей. Вот простой пример : Hash=md5(md5(pass).sha1(salt)) Определить и взломать его будет ещё тот геморрой... Хотя конкретно такой алгоритм я бы не рекомендавал крупным сайтам, т.к. при определении алгоритма взломщик может получить sha1 хеш конкретной соли (админа) и брутить пасс алгоритмом md5(md5(pass)) по маске. Так что лучший вариант это использование разных алгоритмов хеширования для привилегированных и обычных пользователей.(ну или просто при повышении прав пользователя загонять существующий хеш в md5(unix), получая в итоге md5_Unix(md5(md5(pass).sha1(salt)))
да, Gray_Wolf, пока ты это писал я уже убрал тот метод из своего поста. Мысль была в том, что любой кастом алгоритм, если он заранее неизвестен - не брутабелен. До тех пор, пока не станет известен.
