Более того, если ресурсоемкость построения ваших tiger128 + md2 < md5 - вы только облегчаете их построение.
Я специально выбрал два неустойчивых к коллизиям, но очень быстрых алгоритма, чтобы вам было понятнее, о чём речь. Но как мне кажется, вам совсем не интересно то, что я хотел вам донести. UPD: Кормлю толстого, как автобус, тролля. Перетроллить или сдаться?
Ага, вы хотели донести бред, ибо не понимаете, что радужные таблицы без проблем строятся для поиска исходного пароля. А так же не понимаете, что для поиска tiger128 + md2 не нужно строить 2 сета радужных таблиц, они вообще не зависят от алгоритма. От радужных два серьезных способа защиты - рандомная соль. Для каждой соли придется строить свой сет радужных, что безумно затратно. И второе - повышенная вычислительная мощность - почитайте описание алгоритма crypt хотя бы для md5 алгоритма - что значительно увеличивает время построения ранужных. Все, что вы сделали - это упростили жизнь тому, кто будет щелкать все ваши пароли как орехи.
Это клевета. И вся ваша теория только что пошла коту под хвост. Пруф для остальных: http://ru.wikipedia.org/wiki/%D0%A0%D0% ... 1%86%D0%B0 А вам же скажу... Да вы же никогда сами не пытались понять, как эти таблицы сделаны и как идёт связывание этих цепей! Зачем вы людям пудрите мозги?! Не могу понять!
О, ну поздравляю, вы хоть начали гуглить и читать азы. Так вот, если у вас проблема со зрением - я везде говорю _строить_. Таблицы _строятся_ под определенный алгоритм. Свистнув базу из тысячи ваших паролей _строятся_ таблицы по вашему алгоритму, что занимает очень много времени - в зависимости от словаря и/или длины пароля и задействованных символов, но после этого вся база щелкается как орехи.
У нас с вами ничего не выйдет. У меня кроме оскорблений в ваш адрес ничего не получается написать. Скажите, какой вуз вы оканчивали и по какой специальности. Я хоть буду знать, откуда такие умные берутся.
titch, опустив реплики тролля, мне такой подход кажется весьма интересным, так как исключает как минимум пятиминутное гугление такого хэша. А какие бреши можно найти в следующем алгоритме: 1. Пароль криптуется md5 2. Для всего сайта случайно генерится уникальный ключ (назовем его site_id), его можно хранить в ФС - не в бд. 3. Сравнение происходит так: $crypted_pass == md5($original_pass . $site_id). В базе соответственнао хранится именно этот шифр. Таким образом md5(пароля 123) != md5(пароля 123) на разных ресурсах.
<?=RPG?>, в этом есть рациональное зерно. Если вы сворачиваете хэш одним алгоритмом, то нужно использовать соль. Если ваша соль еще приносит пользу кроме то, для которой изначально создавалась, то совсем хорошо
Это не совсем соль, так как ко всем паролям цепляетсядин и тот же ключ. Это всё равно что использовался не 128-битный md5 а какой-нибуть 128-битный md125, т.е. другой алгоритм. Тем не менее соль к системе авторизации я прикрутил и привязку к браузеру заодно, чтобы хищение куки не позволяло зайти с такой же кукой с другой машины. С другой стороны, хищение базы или взлом самого сервека это ппц сайту в любом случае.
ниже ответил понимаешь , я вчера перед написанием этого поста просидел часа 3 в гугле , читал про коллизии , парадоксы дней рождений и прочий бред. Но я не нашёл того чего искал - конкретный пример коллизий. Дай мне хотябы 1 пример двух значений у которых md5 хэш будет одинаковый. Да , я понимаю - это основа того что его нельзя декриптовать каким-то методом - он даёт несколько вариантов исходников , так вот покажите мне эти примеры , а то я реально не могу их нигде найти и то что ты описываешь - я понимаю , но как ты посвотрев на хэш поймёшь что в нём меняли ? А если я буду в хешах местами менять например число 8 и букву a , как ты подберёшь коллизию даже если это возможно ? а если я вообще рандомный генератор на каждый пароль буду пихать с заменами ? 8=a d=x c=y e=4 и т.д сколько у тебя на подбор уйдёт ? лет 100 ? и даже посмотрев на свой хэш ты не поймёшь как он получается а если я по крону буду раз в сутки менять все пароли по рандомному генератору и менять систему замен ? я разумеется в примере не учитываю валидность решения , нагрузку на эти операции и т.д , важно что от конечного результата ничего вынуть не получится. и даже если это возможно - обьясните КАК ? это реально нереально =)
Ладно В общем таким образом можно подобрать пароль с таким же хешем что и у оригинального пароля незная конечный хэш и для этого нужно его менять непосредственно на самом сайте и после каждого ввода смотреть на полученный результат ? Потому что другого варианта я не вижу.
http://ru.wikipedia.org/wiki/MD5 В разделе "Коллизии" Есть 2 блока по 8 штук. Это последовательности 128 байт. Это всё коллизии друг от друга и дают одинаковый хэш.
был конечно же на этой странице в вики , но до этого почему-то не дошёл читая в ней подряд статьи которые вели ещё на другие статьи типа birthday атаки в которой был парадокс дней прождений и т.д и разумеется читаемой мною материал увеличивался в геометрической прогрессии =) короче много чего что не дало дойти до туда )
О, это конечно последний аргумент, когда уже не можешь ничего объяснить, в частности как гениальный алгоритм усложнит построение радужных таблиц.
MiksIr, Хотел по делу ответить, начал перечитывать посты, аж скулы сводит. Мне просто неприятно с вами говорить. http://habrahabr.ru/blogs/algorithm/82941/ - это как таблицы строятся. Мне кажется, что я понял, что вы имели в виду, когда говорили, что радужные таблицы не зависят от хэш-функции. В том плане, что от неё можно абстрагироваться и логика у всех сетов будет одинаковой. да не усложнит он никаким образом. вопрос в том, что я в базе храню в одном поле tiger128($pass).md2($pass). Если у меня пароль будет длиной 10-15 символов, то за полчаса по готовым md2 таблицам, нарезанным под 8< символов пароль, то вы с некоторой долей вероятности найдёте коллизию $col_pass_md2 на мой пароль (несмотря на разницу в длине). Но эта коллизия не будет удовлетворять условию tiger128($pass) == tiger128($col_pass_md2). Если вы построите сет РТ для tiger128, ситуация будет обратной. У вас будет коллизия к моему паролю под tiger128, но она не будет подходить к md2. Т.е. вам нужен будет оргинал или коллизия, которая удовлетворяет сразу 2 алгоритма. Для того чтобы выловить коллизию сразу на 2 алгоритма одновременно (которой может и не быть на конкретной мой пароль для такой маленькой длины), потребуется взаимная рекомбинация цепей. Это своеобразный брутфорс, только на цепях. Рекомбинация цепей при таких объёмах данных вызовет лавинообразный рост памяти или процессорного времени (это уже на ваше усмотрение). Т.е. вам нужны будут не 0,6Тб и 0,6Тб, а чтобы их сопоставить - на порядки большее число памяти, если вы собираетесь хранить сет полной линейной рекомбинации MD2+TIGER128. На это вам потребуется, к примеру, не 22 минуты уже, а поиск оригинала. В случае, если салт известен, наши с вами md5($pass.$salt) и tiger128($pass).md2($pass) - это задачи одного порядка. Другое дело, что вы больше заботитесь о пользователях со слабыми паролями. Хотя от поисков по таблицам (библиотеки паролей) их тоже ничего не спасет. ЗЫ: У меня пароль на почте 18 символов (только со сменой регистра), на серверах - от 10 до 14 символов (в том числе и спецсимволы). А вот если бы у меня базу украли, я бы при%уел... И уже бы никуда не рыпался. И наплевать, как там пароли хранятся.
ну лично я не срусь , для меня важнее узнать ответы , чем помашниться =) так мне ответы ктото даст на поставленные вопросы ? )
А если пароль over 9000 символов, то никакие таблицы не помогут, ага. Давайте определимся - мы говорим не о том, как вы храните свой пароль у себя, и насколько он сложен. Речь о том, как вы собираетесь защищать пароли _своих_ пользователей. Именно это задача разработчика и безопасника. Если вы никогда не разрабатывали сервисы для интернет, то оно и понятно, что базу никто красть не будет, как бы неуловимый Джо рулит. В реальных сервисах база может быть слита кучей способов, а учитывая что часто ее пишут активные посетители php.ru - вопрос "есть ли дырки" даже не встает - дырки есть. И пароли у большинства пользователей, как вы сказали, не по 12 символов, а по 6-8, а длинные пароли наверняка словарные. Что это значит? Вы защитили себя от поиска коллизии, но упростили жизнь построителям таблиц за счет меньшего процессорного времени. И сделали им огромный подарок фразой "а зачем соль", позволив по построенным таблицам прогнать всю базу паролей. Более того, вы им сделали еще один подарок - благодаря защите от коллизии они теперь точно знают - нашли они исходный пароль или коллизию. Теперь "а что мы защищаем". Мы защищаем приватность пользователя. Даже не будем говорить о многоэтапных системах, в которых получение доступа к одной подсистеме не означает получение доступа к другим. А вот пароль - означает. Это будет слишком абстрактно. Поговорим о том, что сдав пароли пользователя вы сделали их уязвимыми для последующих атак на другие сервисы, ибо не секрет, что у многих пользователей одинаковые пароли на разные сервисы. Так же, слив базу пользователей вы можете даже сдать дырку - ее закроют, а вот с паролями, скорее всего, ничего сделать не подумают, ибо не понимают опасности. И расшифровав хотя бы часть паролей - добро пожаловать спам и мошенничество. Обычно это хорошая база для рассылки более серьезных средств атаки, таких как трояны. Итак, еще раз ответ на вопрос "зачем соль". Для того, что бы защитить украденную базу хешей от брутфорс атаки по построенным таблицам. Именно по-этому соль должна быть разной для каждого пароля - добавляя одинаковую соль вы защищаетесь от уже построенных ранее стандартных md5 таблиц, но не защищаетесь от построения таких таблиц для вашей соли. Вторая известная защита от _построения_ таблиц - это увеличение требуемых ресурсов. Это второе место, где вы "облажались". Для 99.99% систем совершенно не важна ресурсоемкость алгоритма шифрования пароля, если он выполняется в приемлемое для отклика пользователю время. Не важно, ибо регистрация и авторизация - это очень редкая операция на фоне других задач ресурса. А вот с точки зрения построения таблиц любое увеличение времени расчета - это адское увеличение времени построения таблицы. Уже посмотрели, как работает стандартный юниксовый crypt? Там _тысячи_ итераций хеширования. Вот и все, что я хотел сказать. Так что не нужно новичкам, которые тут лобают свой говнокод давать вредные советы. Пусть на crypt переходят.
а когда хотя бы часть океана поднимется в Гималаи, то там начнётся хаос и наводнение. спам??? вы адекватный? почитайте ветку, эти базы копейки стоят - купил и юзай. зачем для спама расшифровывать чью-то базу?!?! для мошенничества будут использовать таргетированый взлом и нужную информацию просто хитро отберут. по всем показателям привлечение специалистов по социальной инженерии обходится значительно дешевле, происходит быстрее и с гарантией уж побольше 75% за 22 минуты без всяких Тб. остальное - избыточно. если цель не вы и не ваш клиент, а просто набег варваров, то достаточно будет того, что просто пароль накрыт _любой_ хэш-функцией. а если это не так, то вам уже ничего не поможет) PS: эту ветку еще кто-либо кроме дискутирующих читает?...
Тебя проигнорили, потому что ты спросил "если кот - млекопитающее, то как его надо дернуть за хвост, чтобы он дал молока?" не зная - никак. для того и "ломают базы" на самом сайте ничего не меняют в таких случаях в больших объемах. У себя на компе это делают. Ибо если сайт с открытой регистрацией, и есть доступ к базе, то подбор завершится успешно в рамках одного-двух дней. В случае алгоритма тича при таком раскладе он будет взлома при первом же взгляде на хэши, т.к. известны хэши функций и увидеть, что хэш в базе состоит из двух этих заранее известных - не сложно. т.е. на проекте типа вконтакте или одноклассники если не солить пароли перед хэшированием - это будет большой конфуз в случае слива бд. Соль при этом должна оставаться секретной и храниться глубоко и далеко под семью замками. однако если удалось получить доступ к БД велика вероятность, что действовать через БД будет проще. Например наделить свой аккаунт дополнительными правами. Солить пароль имеет смысл если у тебя нет регистрации, и обладание базой данных не является целью для злоумышленников. Я себе такую ситуацию в живую представить не могу. В тех же соц.сетях доступ к аккаунту нужен исключительно для рассылки спама и вирусов. Однако есть свободная регистрация, что нивелирует вобще ценность взлома базы, ибо данные по всем людям и так в 70% случаев свободно доступны всем зареганым, рассылка может производиться всеми зарегаными, обладание доступом к аккаунту не несет никакой юридической силы и значит бессмысленно и бесприбыльно. Т.е. если кто-то сольет базу с соц.сети, то получит кучу знаний о людя и их имейлах, что можно использовать для точечных спам-рассылок по возрасту/полу/имени/месту жительства и т.п. Но при этом, за 1 минуту можно зарегать акк и получить доступ ко всему этому уже из коробки =) Так что - смысла нет париться. В случае если свободной реги нет, то смысл взлома паролей тоже слабо понятен. Во-первых проще заслать инсайдера, если обладание БД не сама цель. Во-вторых, в таких случаях как раз обладание БД и есть цель и ценность, и после слива БД никто ваши хеши даже смотреть не будет.
По сути соль - это религия. Т.е. нельзя скзать что это плохо или неправильно. И хорошо, и правильно. Это правило хорошего тона - быть выбритым, носить чистую одежду и солить пароли. Но если вам вгонят анальный зонд - правила хорошего тона вас не спасут.
а я вот считаю, что это их беда... [/quote]соль должна быть разной для каждого пароля[/quote]Где же вы батенька предлагаете хранить разную соль?
не в обиду, но как ты это увидишь?)) если даже вот такие вопросы возникают: http://www.php.ru/forum/viewtopic.php?t=31120 ps: вопрос риторический, и я понимаю, что всё логичное логично) никто не станет плодить ужасных мутантов в нормальных продуктах