Так ли безопасно хранение пароля в виде хеша
Практически любой, даже начинающий разработчик, скажет вам, что пароли в базе надо хранить только в виде хеша (например md5). Это обеспечит их сохранность и увеличит безопасность системы в целом. Так ли это на самом деле?
В действительности нет, не так. Безопасность, да и сохранность, конечно повысится, но не очень сильно. В интернете уже давно есть базы хешей многих паролей. Трехминутный поиск только по Яндексу вывел меня на следующие сайты - MD5decrypter (568 002 хешей) и Insidepro (10 148 884 хешей). Уже не мало, ведь так? А это только открытые проекты и только по md5. Я думаю у любой серьезной хакерской группы есть свои базы, благо, с наличием бот-сетей распределенные вычисления перестают быть проблемой.
Кто-нибудь самый догадливый предложит, а давайте к пользовательскому паролю добавлять свой секретный длинный префикс. Ну или делать, например, md5 от md5. Взломщик никогда об этом не догадается и пароль не подберет.
Не поможет. В действительности при взломе хеша нам важен не оригинальный пароль, а поиск коллизии. Ведь неважно введем мы пароль 76854 или Fhndkts если md5(’76854′) будет совпадать с md5(’наша_секретная_строка’.'Fhndkts’).
Единственная проблема, что вариантов хешей все таки очень много и они будут занимать очень большое место в базе данных. да и поиск по ним потребует очень длительного времени.
Однако и эта проблема решается при помощи Rainbow Tables. Используя их мы на несколько порядков уменьшаем размер хранимой базы и скорость поиска пароля. Более подробно об этом можно почитать здесь и здесь. Для построение таких таблиц также нужны распределенные вычисления. И такие проекты есть - Rainbowcrack. Размах впечатляет - 2,628 таблиц, 102,080,000,000 цепочек (в каждой цепочке примерно 1000-1500 паролей), 1.49 Тб данных. Есть также российский подобный проект, но пока добились они намного меньшего.
Вот и как теперь хранить пароль?
—————
Ещё по теме:
Написано Декабрь 17, 2007
Комментарии
mihailt - декабря 17, 2007 13:48
прибавляем соль и тримим пароль. не поможет? ;)
mivlad - декабря 17, 2007 14:08
Упомянутый префикс («соль») может быть довольно длинным, и состоять из любых значений байтов (не только из печатных символов, то есть). А дающее коллизию значение скорее всего тоже будет довольно длинным, и опять-таки состоящим не только из ASCII.
Ну а 256 во всего-навсего шестой степени — это 281474976710656, что уже больше, чем количество хешей в том самом rainbowcrack.
Дмитрий Донченко - декабря 17, 2007 14:34
В свое время когда писал статью по безопасности серверов на FreeBSD там рекомендовали изначально изменять алгоритм криптования паролей пользователей с md5 на blowfish.
Но с этим было связано сразу много проблем/вопросов, почти весь софт по умолчанию работает с md5.
Alexander - декабря 17, 2007 15:52
Так я проспорил пиво (заведомо зная) одному товарищу из локалки, он простым перебором, ограниченным лат. алфавитом и цифрами, больше суток md5 расшифровывал.
ИМХО, не защиту паролей, а защиту сервера нужно продумывать. Пользователи сами виноваты в своих qwerty паролях.
Влад - декабря 17, 2007 16:43
Есть ещё sha1 (пока есть теоретическая возможность хака оного). Есть sha2 — его пока не хакнули, но раз хакнули sha1, то и sha2 можно.
Есть ещё blowfish, как говорил выше Дмитрий.
Не в md5 счастье :)))
Александр Мальцев - декабря 17, 2007 17:13
Ну, всё, теперь всякие сообщения на универсальных или посреднических сервисах, что они хранят пароль в хэше — на меня действовать уже не будут :)
mivlad - декабря 17, 2007 17:22
2 Александр Мальцев:
Даёшь OpenID везде! :-)
Vyazovoi Pavel - декабря 17, 2007 20:24
А если полученный хеш потом ещё раз прогнать по алгоритму, т.е. получить хеш из хеша, то радужные таблицы и базы хешей уже не помогут ;) Останется только перебор, хотя перебор тоже врядли поможет в таком случае ;)
Или я чегото непонимаю? Я незнаю сам алгоритм получения хеша md5 мож двойной хеш и неимеет смысла я хз.
Кстати в последнем комменте очень хорошая идея — можно ведь добавить к генерации и проверки хеша свой алгоритм =)
Vyazovoi Pavel - декабря 17, 2007 20:27
например делать к каждому символу смещение на два символа а затем получать хеш... действительно вариант. Спасибо за идею пойду переделаю авторизацию на пока ещё не готовых проектах =)
4m@t!c - декабря 17, 2007 20:56
Для большинства проектов md5 пароля с «солью» хватит с головой — потому что одна из основных целей сделать пароль нечитаемым. Так же для большинства проектов «цена реализации» такого md5-решения вполне оправдана.
Да, коллизии никто не отменял, но и брутфорс тоже. Ни один алгорит ширования не убережет от пользоавтелей, которые любят пароли типа qwerty или 11111.
jeka911 - декабря 17, 2007 21:03
Конечно, здесь все сводится к объему затрат на взлом из хеша. Абсолютно защитить невозможно, но каждое извращение уменьшает вероятность взлома на несколько порядков.
В любом случае — часть процесса надо выносить из базы в код, причем так, чтобы промежуточное значение (обратный md5 от значения в базе) не было похоже ни на md5 ни на сам пароль. Т.е. при двойном хэшировании, перестановке-смещении символов, скорость взлома пароля при удачном раскладе для взломщика падает всего в два раза.
Алексей Д. - декабря 20, 2007 20:55
Денис, я вот чего не могу понять. Откуда взялось число различных хешей 402 000 000 миллиарда. Их реально 2^128, то есть 340282366920938463463374607431768211456, что есть на 21 порядок больше.
Даже если использовать «тонкие» таблицы, то для всех хешей понадобится объём информации, который не записать совсем никак.
VoiD - февраля 17, 2008 16:46
по поводу OpenID — зато если его взломают, весело очень будет(
|
