md5

[Bright]

Я про функцию md5();
Насколько я понимаю, пароль юзера шифруется, сохраняется в базе.
А потом при входе юзера, он вводит пароль, его пароль тоже шифруется и сравнивается с тем, что в базе.
Правильно?

И отсюда два вопроса.
Увеличится ли безопасность если...
1. Использовать md5 два раза.
2. Заменят в полученой строке символы.

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

[Crazy]

Сообщение от Bright

Увеличится ли безопасность если...
1. Использовать md5 два раза.
2. Заменят в полученой строке символы.

1. Незначительно ухудшится.
2. Не изменится.

[Skubent]

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

[juggy]

Сообщение от Crazy

1. Незначительно ухудшится.
2. Не изменится.

А почему это он должен ухудшится? Вот то, что он не улучшится, это понятно. Но хуже-то что?

[Crazy]

Сообщение от juggy

А почему это он должен ухудшится?

Ввиду возможности коллизий. Если у нас на входе N паролей, то после применения md5 мы получим N1 кодов, причем поскольку некоторые пароли порождают одинаковые коды (это и есть коллизия), то N1 <= N. При повторном применении md5 возможны коллизии уже между кодами. Т.е. N2 <= N1. И т.д.

[Skubent]

А вообще, по поводу хэш-функций гугл отдает вот такую ссылку для ознакомления:
http://antichat.ru/txt/hashes/

[Bright]

то есть md5() - это предел?
взломщик получает хэш, расшифровывает и...

вообще будет ли лучше если по какому-либо алгоритму менять хэш, а потом при проверке обратно... ?

[Смольный (Smolniy)]

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, сам виноват!

[Racer]

1. Вот это грамотно!
2. Надо теорию почитать
4. А вот с бадунища сможешь потом вспомнить, что за смешное слово было? особенно, если паролей много? у меня такое бывало частенько... приходилось всю базу своих (тех что в мозгу еще остались) паролей перебирать... и еще нафантазировать столько же, пока не подошло...
5. Обычно когда кто-то своими кривыми руками начинает копаться в исходниках, а особенно в исходниках крипто-алгоритмов... Боюсь защищенность от этого только уменьшится.

[Racer]

6. Кстати, ничего страшного в этом пароле и тому подобных нет. Просто его использовать надо там, где безопасность не нужна. Вот как раз в форумах или, например, объявления на JOB.RU ... Это каким надо быть маньяком, чтобы ломать эти пароли. Точнее, не вижу повода. разве что баловство...