Просмотр полной версии : md5
Я про функцию md5();
Насколько я понимаю, пароль юзера шифруется, сохраняется в базе.
А потом при входе юзера, он вводит пароль, его пароль тоже шифруется и сравнивается с тем, что в базе.
Правильно?
И отсюда два вопроса.
Увеличится ли безопасность если...
1. Использовать md5 два раза.
2. Заменят в полученой строке символы.
То есть если взломщи получит хэш.
он его раскодирует утилитой md5inside (rкажется ак называется)
а там еще 1 хэш. и к тому же не правильны.
то есть без получения исходного пхп кода, он пароль не расшифрует.
так или нет?
Увеличится ли безопасность если...
1. Использовать md5 два раза.
2. Заменят в полученой строке символы.
1. Незначительно ухудшится.
2. Не изменится.
Принято помимо хеша пароля хранить еще какие-нибудь данные о пользователе, причем отдельно от хеша. Тогда усложняется алгоритм авторизации, но повышается степень надежности.
1. Незначительно ухудшится.
2. Не изменится.
А почему это он должен ухудшится? Вот то, что он не улучшится, это понятно. Но хуже-то что?
А почему это он должен ухудшится?
Ввиду возможности коллизий. Если у нас на входе N паролей, то после применения md5 мы получим N1 кодов, причем поскольку некоторые пароли порождают одинаковые коды (это и есть коллизия), то N1 <= N. При повторном применении md5 возможны коллизии уже между кодами. Т.е. N2 <= N1. И т.д.
А вообще, по поводу хэш-функций гугл отдает вот такую ссылку для ознакомления:
http://antichat.ru/txt/hashes/
то есть md5() - это предел?
взломщик получает хэш, расшифровывает и...
вообще будет ли лучше если по какому-либо алгоритму менять хэш, а потом при проверке обратно... ?
то есть md5() - это предел?
взломщик получает хэш, расшифровывает и...
И как ты представляешь себе этот процесс? Закапывает хэш в ямку, посыпает солью, поливает водой, говорит волшебные слова "крэкс-пэкс-фэкс" и к утру вырастает дерево, на котором вместо листьев -- бумажки с паролями? :)
вообще будет ли лучше если по какому-либо алгоритму менять хэш, а потом при проверке обратно... ?
И чего ты хочешь этим добиться? :)
И как ты представляешь себе этот процесс? Закапывает хэш в ямку, посыпает солью, поливает водой, говорит волшебные слова "крэкс-пэкс-фэкс" и к утру вырастает дерево, на котором вместо листьев -- бумажки с паролями?
нее.... надо говорить "абракадабра", иначе не вырастет :)
И чего ты хочешь этим добиться?
увеличения безопасности.
увеличения безопасности.
И за счет чего, на твой взгляд, здесь увеличится безопасность? :)
Он хочет сказать, что сваяет двухсторонний алгоритм шифрования, более устойчивый к вскрытию, чем односторонний md5 :)
После шифрования прибавляй к ascci-коду первого символа хеша заветную цифру (например, длину того же хеша или константу - зависит от степени паранойи), а при расшифровке - отнимай :) Никто не догадается :)
После шифрования прибавляй к ascci-коду первого символа хеша заветную цифру (например, длину того же хеша или константу - зависит от степени паранойи), а при расшифровке - отнимай :) Никто не догадается :)
1. Как он догадается, что используется md5?
2. Если он имеет такой добрый доступ, что смог прочесть все хэш-коды, то что помешает прочесть и исходник? :)
я всего лишь спросил.
да или нет.
мне сказали нет.
всё, всем спасибо.
2crazy:
1. md5-хеш всё-таки по виду можно отличить скажем от pgp
2. Да, тут ты прав... :) Хотя доступ может быть и тока к базе, скажем, через SQL-injection
На мой взгляд шифрование (кодирование-декодирование) и хеширование (получение хеш-функции, из которой исходный текст уже нельзя получить) это несколько разные вещи.
Безопасность действительно увеличится, если увеличится длина и сложность пароля.
А еще, если усложнить авторизацию (ну ограничить число неудач, ввести интервал повтора), и исключить таким образом автоматические средства взлома. Если конечно еще не добрались до хеша :) .
Да и вообще есть ли смысл извращаться - что за важная информация? md5 вполне остановит непрофессионала, а профессионал попросит деньги, которые в итоге должна окупить скрываемая информация :) . Если информация и правда дорогая, то и защищать ее надо другими методами.
Исходный текст из хеша получается элементарно. Но долго. Программа берёт символ "1", шифрует, сравнивает хеш, берёт "2"... берёт "zZ"... берёт "thepassword"... либо по словарю либо тупым перебором... Ещё есть проги, которые юзают готовые таблицы шифрованных строк, что ускоряет работу в сотни раз... Но весят эти таблицы десятки гигов...
Цель и средства - стоит подумать...
Это элементарный метод "грубой силы", которым, бесспорно, при достаточной технической подготовке, словаре, и слабом пароле "легко" подбирается пароль. Но в ином случае к примеру пароль d23rGhj6b52dUlzEN83MfioD- подбор пароля может затянуться на долгие года :)) . Человеческий фактор - вот слабое место :) кто ж будет задавать такой пароль? Только параноик...
Исходный текст из хеша получается элементарно.
Любая задача решается элементарно. За две операции:
1. Начать
2. Закончить
Но это ничего не говорит о том времени, которое придется на это потратить. :)
Но в ином случае к примеру пароль d23rGhj6b52dUlzEN83MfioD- подбор пароля может затянуться на долгие года :)) .
Ошибка. В действительности с большой вероятностью гораздо раньше будет найден другой, более короткий, пароль, дающий то же значение md5. И он вполне успешно "откроет дверку".
Желающие могу самостоятельно подсчитать максимальную эффективную длину пароля для случая использования md5.
доступ к базе - sql-инъекция.
расшифровать хэш утилита md5 inside.
в яндексе находится легко.
у ничтожно малого количества пользователей пароли вида "d23rGhj6b52dUlzEN83MfioD" :)
на любом форуме есть, кто-нибудь у кого пароли типа god, love и тд...
и такой чел подставляет безопасность.
расшифровать его пароль - плевое дело.
Ну эт да... тут уже всё портят особенности алгоритма.
Так вот и речь о том что для больших секретов это не годится :) а для форумов и прочей лабуды - в самый раз :))
2 Bright: доступ к базе - sql-инъекция. Это уже давно известный прием и все более-менее свежие форумы или сайты, в которых программеры хоть немного об этом знают, используют не очень-то сложную защиту от этой напасти. А вычислить какой именно запрос "инъектировать" для неизвестных движков тоже не дело одной минуты.
А сложность пароля каждый определяет для себя сам - кто когданть терял свой
ICQ-UIN, наверняка уже не будет использовать пароль типа '123' или 'qwert' :))
я всё-таки немного паранойик - пароли типа ThEpAs$w0rD - самое то: разный регистр, спецсимволы, разные раскладки... :) А ещё лучше, чтобы небыло смысла... только тогда запомнить сложно, придётся записывать, а это черевато...
Или ещё круче: я не помню пароль, но мои пальцы помнят по каким клавишам надо стучать... например qAwSeDrF :)
неповеришь, но такой пароль был у одной моей знакомой :)) только с другим регистром.
Надо делать так - запоминать не пароль, а систему его генерирования. Например, помнить, что через каждую четную букву идет название сайта, а через нечетную - дата твоего рождения и в конце приписывается имя сайта наоборот, а регистр меняется каждые 3 буквы - ну короче каждому своё :) . И тогда нопроблем главное чтоб эту систему ктонть не узнал, а то тогда все твои пароли откроются :)) . Или собственно, не забыть саму систему :))
Есть проги-хранители паролей, но их с собой постоянно не потаскаешь... не удобно, да и неизвестно, если узнают пароль ко всей базе паролей, или просто она пропадет, то - крышка.
Смольный (Smolniy)
20.11.2005, 20:56
1. Применяют (кажется даже в vbulletin) такую вещь. При заведении нового пользователя и получении от него пароля, его хэшируют md5, затем генерят короткую (3 байта вроде) случайную строку, вносят ее в БД в параметрах пользователя и хэшируют предыдущий хэш с этой строкой (называется salt, "приправа") (например, ф-цией crypt), и это дело уже пишут в базу. Когда юзер логонится, его пароль хэшируют (нередко еще на уровне клиента, чтобы пароль не ходил по сети в чистом виде), берут по имени из БД salt и так далее. Для чего это нужно. Если некто наделает хэшей стандартным md5 для десятка миллионов простых паролей (и поместит их в БД), то получив хэш пароля он быстро sql запросом получит соответствующую строку. Здесь же придется crypt все эти пароли с salt вытащенного пользователя, что ресурсоемко. То же касается простого поиска перебором (без готовой базы хэшей), трудоемкость удваивается.
2. Вероятность того, что при переборе коротких паролей мы найдем такой, хэш корого совпадет с хэшем данного "трудного" пароля, и он сработает как ключик, при этом им не являясь, я полагаю, ничтожна. Гораздо больше вероятность того, что данной строке в 5 байтов эквивалентна строка длиной 200 байтов, еще одна 4312 байтов и т.д.
Экспериментальными подтверждениями не располагаю :)
3. md5 inside ищет пароль путем перебора, т.е. генерит строки, хэширует их и сравнивает с вскрываемой. Защищаться от этого можно только одним способом: задавать длинный и сложный пароль. Пароль wwwwwww будет взломан моментально, потому что именно подобные строки проверяются в первую очередь.
4. Лично я использую для паролей такой алгоритм: придумываю русское слово, желательно посмешнее, желательно ненастоящее (например, слово "хмырьище"=[vshmbot), и ввожу его в англ. раскладке, меняя регистр. Запомнить просто, результирующая строка как правило достаточно безумна. Большинство программ взлома не ориентированы на русскоязычное мышление ;)
5. Всегда можно "изменить" исходную программу, изменив ручками процедуру шифрования (как правило, просто какая-либо математика), желательно при этом добиться удлинения хэша. Конечно, это создает определенные проблемы при апгрейдах софта, и это "неправильный" путь, но он результативен. Так или иначе, он сделает использование данного хэша для программ сорта md5 inside невозможным в принципе. Для эффективного взлома необходимо будет также узнать упомянутую математику, а доступ к файлам серверного софта у взломщика есть далеко не всегда (да еще, например, пожатого zend-ом). В 95% случаев взломщики малоквалифицированы, начитались Хакера, подловили нерадивого админа на необновлении софта и заполучили голую БД. Конечно, бывает, получают полный доступ, носредства побороться есть всегда. Просто это все трудоемко.
6. Тот, кто придумал себе пароль love, сам виноват!
1. Вот это грамотно!
2. Надо теорию почитать :)
4. А вот с бадунища сможешь потом вспомнить, что за смешное слово было? особенно, если паролей много? у меня такое бывало частенько... приходилось всю базу своих (тех что в мозгу еще остались) паролей перебирать... и еще нафантазировать столько же, пока не подошло...
5. Обычно когда кто-то своими кривыми руками начинает копаться в исходниках, а особенно в исходниках крипто-алгоритмов... Боюсь защищенность от этого только уменьшится.
6. Кстати, ничего страшного в этом пароле и тому подобных нет. Просто его использовать надо там, где безопасность не нужна. Вот как раз в форумах или, например, объявления на JOB.RU ... Это каким надо быть маньяком, чтобы ломать эти пароли. Точнее, не вижу повода. разве что баловство...
Смольный (Smolniy)
21.11.2005, 03:51
Копаться в коде, конечно, надо прямыми ручками.
Хэш-коллизии md5 достигаются на P4 1.6Ghz за ~45 минут. Это существующая практика. Но оно относится к обнаружению двух строк с одинаковым хэшем - а не к поиску строки, хэш которой равен заданному. Иначе весь интернет был бы уже разломан вдоль и поперек. Практическая информация о коллизиях md5 (теоретическая была очевидна с самого начала, т.к. входных строк однозначно больше, чем возможных хэшей с фиксированной длиной) была громко озвучена прошлым летом (2004), однако, как видим, за год ничего кошмарного не приключилось. Весной этого (2005) года прошло сообщение, что чехи соптимизировали алгоритм перебора и находят коллизию для хэша за 8 часов на той же машине, что указана выше. Однако, опять же, катастрофы не случилось. Просто на самом деле важные вещи закрывают гораздо надежнее, кроме того прямой алгоритм md5 в чистом виде используется не так часто, существуют гораздо более надежные (трудоемкие) алгоритмы. Наконец, md5 - в основном алгоритм "для маленьких" применений, типа форумов и прочей интернетовской шушеры. Опять же, строка, эквивалентная по хэшу исходной, имеет вовсе не ту же длину и скорее всего отсечется на этапе входа. И вообще, раскрытие md5 - это последний этап на длинном пути взлома комплекса. Если вы получили полный доступ к хостингу, то гораздо проще втихаря добавить хак, который будет просто сохранять вводимые людьми пароли и имена и через месяц иметь все что надо, а не долбиться с разгадыванием паролей при немалой вероятности, что пароли просто сменят. :)
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.