Защита от взломов хешей (мои мысли...)
 

В общем это мне пришло в голову еще давно, но только сейчас я решил это выложить, а точнее спросить, будет ли это эффективнее. Лучше всего объяснять на примере, поэтому я его покажу. Есть простенький скрипт регистрации - авторизации. Регистрируется пользователь с паролем 123456. Современные обычные (без соли) движки заносят в БД md5 хеш пароля, то есть e10adc3949ba59abbe56e057f20f883e. Дальше, когда пользователя авторизируется, md5 хеш введенного пароля сопоставляется с md5 хешем в базе, и если они равны, то авторизация проходит удачно. Так вот, если же сделать алгоритм, который бы заносил не весь хеш, а затирал некие символы, т.е. заносил бы, например e10a*c394*ba59a*be56e057*20f8*3e. При авторизации, скрипт разделяет хеш пароля точно так же и сопоставляет его с хешем в базе. Если затереть всего один символ вероятность распознавания пароля становится уже в 16 раз! ниже. А если затереть пять , то соответственно, вероятность становится в 16*5 = 80 раз ниже. В этом алгоритме также есть и свои недостатки - коллизии. НО вероятность коллизии все равно очень мала, даже при затёртых 5 символах. В общем вот, что вы об этом думаете?

Атака по неполному хэшу решает процесс перебора это раз.
Второе, никто не мешает сгенерировать все возможные хэши по маске и брутить уже пачку хэшей. Даже если какой-то совпадёт по маске, велика вероятность что это не коллизия а именно искомый хэш. Идея имеет право на жизнь, но для опытного хэшкрякера не является особым препятсвием для брута неполного хэша. Вероятность подбора пароля не падает, а как раз увеличивается, раз сужается область значений хэшфункции, т.е. ситуация коллизии нас при этом устроит. Единственная защита это соль + более медленный алгоритм хэширования, что и используется, к примнеру md5(unix) отчасти решает проблему защиты пароля от прямого перебора из-за своей медлительности, но по словарю атака остаётся актуальной (точнее даже сказать так можно, что только по словарю актуальны, остальные атаки очень затратны по времени.)

Как именно?
Да, но при переборе 80 хешей, скорость будет меньше, чем при 1.
Наверное, но прогнать по сервисам хэшкрякинга такой хэш пока невозможно.
Но вероятность коллизии небольшая.

проще сделать свой алгоритм шифрования и проверки :)

Зачем эти заморочки, если есть алгоритмы которые задолбааешься брутить?

mailbrush ты пытаешься создать свой устойчивый к бруту алгоритм? Тогда направление не вполне верное ИМХО

SHA1(md5)

Я ничего не пытаюсь сделать, я просто спрашиваю, будет ли устойчивым это от брута. Точнее, не устойчивым, а устойчивее, чем обычный 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 хэше и пропорционально колличеству одновременно перебираемых.

А если такое решение

Вы не поверите но логины хранятся в той же БД что и пароль с солью :)

Мне больше нравится мысль запихивать в хеш 2 соли, вот это точно неслабо сократит время брута...

Gray_Wolf, естественно логин в базе не записан.

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

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


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

Математики такие алгоритмы годами разрабатывают... ;)
Да и в любом случае, если известен алгоритм - значит можно будет и атаковать по словарю. От этого не защитишься.
Ну а от атак иными, чем словарь методами - вполне защищают и многие уже существующие аналоги

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

Мне кажется что лучшей защитой является простая нестандартная комбинация стандартных методов хеширования.
Т.е. без доступа к исходникам определить её не просто, а так-же даже при её определении придётся самому писать модули для брута таких хешей.

Вот простой пример : Hash=md5(md5(pass).sha1(salt))
Определить и взломать его будет ещё тот геморрой...
Хотя конкретно такой алгоритм я бы не рекомендавал крупным сайтам, т.к. при определении алгоритма взломщик может получить sha1 хеш конкретной соли (админа) и брутить пасс алгоритмом md5(md5(pass)) по маске.

Так что лучший вариант это использование разных алгоритмов хеширования для привилегированных и обычных пользователей.(ну или просто при повышении прав пользователя загонять существующий хеш в md5(unix), получая в итоге md5_Unix(md5(md5(pass).sha1(salt)))

да, Gray_Wolf, пока ты это писал я уже убрал тот метод из своего поста.

Мысль была в том, что любой кастом алгоритм, если он заранее неизвестен - не брутабелен. До тех пор, пока не станет известен.

Алгоритмы хеширования и придумали какраз потому что рано или поздно алгоритм становится известен.

Защита является только тогда ТРУ, когда алгоритм известен, но взлом невозможен.

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

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


upd.
что же до админского акка - то и обычный md5 с 18-символьным пассом ^a6(^sk9!2&`~*_+:X - уже небрутабелен.
Так что думать нужно в 1 очередь о безопасности хранения заведомо простых паролей, которые, как раз таки и сверх-уязвимы к атаке по словарю.

upd2.
хотя идея с тем, чтобы каждому акку прописать дополнительную - собственую - соль - тоже тру.
так что я склоняюсь, пожалуй, не к md5(pass.const) а к md5(pass.salt.const) :cool:
по-моему при неизвестном const - супер. при известном же... просто соль => если сольют базу, то снимется всего 45% аккое, а не 65%, как у md5, которые брутятся одновременно сотнями тысяч. :D

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

По поводу md5(pass.salt.const) - разумная идея. Разве что мд5 поменять на что-либо менее быстрое. или вместо пасса сделать sha1(pass) по желанию.

если бы у бабушки был «перец», она была бы дедушкой.
чаще всего стоит задача сломать акк админа, чтобы получить доступ к серверу.
можно попытаться запутать взломщика еще одним способом - фиксированной заменой символов при генерации хэша. хэш состоит из набора символов [a-f]+[0-9], делаем замену символов при генерации, к примеру:
a->3
f->2
.......
5->c

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

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

Кое-что придумал:

MD5(123456): e10adc3949ba59abbe56e057f20f883e
перед вторым MD5: 13c93fbc0470cb0000000000000000000
Конечный продукт: d23f62509ec1c377a9744174e325ee63

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

а что если разделить хэш на 3 неравные части
e10adc3949ba59abbe56e057f20f883e
разделить:
e10a\\\dc3949ba59abbe56e0\\\57f20f883e
и поменять между собой( 2\\\1\\\3 ) например

Ну какбе всё сказал.

2WNZRS
идея конечно неплоха, но всё в итоге сводится к тому что хешкрекеру придётся самому писать модуль хеширования. Хотя согласен что на скорость брута это неслабо повлияет...


2tshift имея доступ к исходнику востановить изначальные хеши это дело 10 минут, а незная алгоритма даже md5(pass.const) с длинной константой взломать невозможно...

На следующую мысль меня подтолкнули моды для форумов, где в качестве пароля загружается картинка...

http://wnezros.homeip.net/sec/pass.php
(localhost, есть сервер не найден, значит комп офф)

чтобы посмотреть сорсы нужно написать логин "source"

Чтобы пробрутить хэш пасса нужно миллион лет, если не больше...
Пароль получается из 699 символов.

Да совсем не нужен пасс такой бешеной длины )
оОВ8786;%(ЦвкjaоJKLfjs - вот такой пасс даже 20 компами не сломать.
А если он будет ещё и в MD5(Unix) то ... ^^

такая длинна получается из печати:
10х10 = 100
цвет кодируется в rgb (6 символов), 100 x 6 = 600 + разделители = 699

в принципе если такое куда-то внедрять, то размер надо уменьшать, например до 5х5

Усди уж на то пошло,то:

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

Есть 2 пути защиты хэша:
1. использовать в добавок к паролю динамичную инфу, но эту инфу надо всёравно надо где-то хранить
2. хранить скрипт хэширования на не взламываемом отдельном сервере

Остальные способы лишь затрудняют разхэширование

Что это такое? Что я пропустил? Лебедь реверснул мд5? :/

разхэширование:
преобразование хэша в исходный пароль любым способом (md5 - брут)