Под впечатлением от утчеки (http://www.opennet.me/opennews/art.shtml?num=34033) нескольких миллионов хэшей паролей пользователей социальной сети LinkedIn, Poul-Henning Kamp, объявил (http://phk.freebsd.dk/sagas/md5crypt_eol.html), что созданную им в 1995 году реализацию системы хэширования паролей md5crypt больше нельзя считать безопасной. Несмотря на то, что для привлечения большего внимания для проблемы создан CVE-идентификатор уязвимости (CVE-2012-3287), уведомление не связано с выявлением какой-то новой проблемы безопасности, а лишь указывает на потерю актуальности md5crypt (расширенный вариант MD5, более стойкий к подбору из-за более высокой требовательности к ресурсам при генерации хэша).
По словам автора md5crypt исчерпал себя как алгоритм хэширования паролей, так как современные инструменты подбора паролей, благодаря задействованию средств GPU-акселерации, могут восстановить любой восьмисимвольный пароль по хэшу за несколько дней. Похожая ситуация наблюдалась в 1995 году в отношении алгоритма DES. Так как во многих системах для хэширования паролей по умолчанию по прежнему используется md5crypt, Poul-Henning Kamp призвал пользователей и разработчиков ОС перейти по умолчанию на более стойкие алгоритмы, такие как SHA-512 и BLOWFISH.URL: http://phk.freebsd.dk/sagas/md5crypt_eol.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34057
Очень большой процент паролей от LinkedIn был восстановлен из хэшей за достаточно краткий срок. Правду глаголит.
А переходить на BLOWFISH или SHA-512 он не советовал и не указывал конкретный метод шифрования. Он дал пару рекомендаций по тому, как усложнить восстановление пароля из хэша.
В интернете есть хорошие статьи о том, как правильно солить хэши и как их хранить.
> В интернете есть хорошие статьи о том, как правильно солить хэши и
> как их хранить.Про соль в точку.
В linkedin хеши были без соли, а это полный фэйл - потому так быстро и расшифровали пароли.
Их не расшифровали, а подобрали. Это важно.
> Их не расшифровали, а подобрали. Это важно.Да, так будет точнее.
Правильно будет так: md5 без соли подбирается на порядки легче, чем с солью.
> А переходить на BLOWFISH или SHA-512 он не советовал и не указывал конкретный метод шифрованияВажнее правильно применять алгоритм, а не бездумно заменять один на другой. Замена MD5 на SHA-512 увеличит сложность расчета ну максимум втрое (не знаю, насколько SHA медленнее), да еще взломщику придется запасти в 4 раза больше места под хэши - вот и все преимущества. Как правильно замечено, необходимо солить, и желательно еще многократно хэшировать пароль - без этого будет мало толку от применения новомодного алгоритма
> BLOWFISH
А разве есть смысл на него переходить? 64-битные блоки это каменный век
Он опечатался,имелось в виду Threefish
> Он опечатался,описался.
Тонко.
> описался.Обосрaлся.
>многократно хэшировать пароль - без этого будет мало толку от применения новомодного алгоритману что за бред...
Скорее всего имелся ввиду bcrypt - http://ru.wikipedia.org/wiki/Bcrypt
Просто вместо 8-мисимвольных нужно поднять минимальный порог до 10--12.
Ну были пароли 123456 будут 12345678.
> Ну были пароли 123456 будут 12345678.*1234567890
> *1234567890********** (troll mode password - половина кулхацкеров сильно обломается).
Это не выход. С появлением сенсорных экранов всё больше распространяется метод проверки пароля по графическому ключу. Вот это действительно увеличивает устойчивость пароля с пользовательской стороны. А серверная часть она никуда не девается - хранить пароли надо как можно надёжней.
Это чушь.
В лучшем виде графический ключ представляет собой числовую матрицу.
В худшем - числовое значение вершины графа.
Итого если у вас матрица4х4, то если я не ошибаюсь, перебор пройдет достаточно быстро =)Это жосский фэйл и равносильно шифрованию цезарем =)
Так что убейтесь апстену, сударь =)
На самом дел это вы тупите.
Сенсорный ввод невозможно (или трудно) автоматизировать.
А если представить, что тыкают пальцем по объектам абстрактной картинки, а картинка для каждого пользователя может быть своя и даже не храниться на сервере вместе с паролями? Допустим картинка разрешением hd-ready разбивается на несколько сотен квардатов и надо нажать 5 раз на разные, а результат потом еще жестко хешируется, то легко ли будет подобрать пароль?
А если результат нажатия - не номер квадрата и не его координата, а хеш кода среднего цвета этого квадрата или еще какая функция ..
"5 из 900" (несколько сотен квардатов и надо нажать 5 раз на разные) ГОРАЗДО легче подобрать, чем "1 из 999999" (1 число из 6-значного цифрового пароля). Для равной сложности вам придётся настолько увеличить сложность картинки...
и как всегда все забыли о бедных пользователях. которым нафиг не упёрлись все эти головоломки.
http://ru.wikipedia.org/wiki/СочетаниеОтвет для 5 из 900, если вдруг слабо посчитать: ~4.9*10^12.
> Ответ для 5 из 900, если вдруг слабо посчитать: ~4.9*10^12.Для HD (1920х1080) 39х23=897 клеток. сторона клетки ~49 пикселей и 12 мм, на мониторе 475х270 мм.
Число комбинаций 897х896х895х894х893= ~5,74*10^14 .
Стойкости хватит, только какая радость этим пользоваться...
Да-да 1 из 583954474521600 ГОРАЗДО легче подобрать, чем 1 из 999999.
Ваня, ты - дурак.
> Ваня, ты — дурак.это тебе любой Кэп Очевидность скажет, даже начинающий.
Спасибо кэп.
>кода среднего цвета этого квадратавам дальтоники яйца оторвут.
Дальтонику не надо видеть цвет, он жмакает на объекты на фото (проткни всех врагов на фото с выпускного =). Потом алгоритм на клиенте высчитывает результат по этому квадрату на этой фотке и все. На всяких фконтактиках можно хранить эту фотку в фотоальбоме, а какую фотку использовал в последний раз будет знать только клиент.
Для планшетов д/б удобно.
Будет нужно тем, кому нужны безопасность и удобство. Кому нужно только второе и дальше будут юзать пароли 123.
То то где то тут писалось что фбр не могло разблокировать планшет и только терморектальный способ помог его разблокировать - но оно ясно что фбр лохи и не прислушались к вашему савету что 4х4 хня
> фбр не могло разблокировать планшет и только терморектальный способ помог его разблокироватьТо они просто новый термроректальный криптоанализатор решили опробовать.
> То то где то тут писалось что фбр не могло разблокировать планшет
> и только терморектальный способ помог его разблокировать - но оно
> ясно что фбр лохи и не прислушались к вашему савету что
> 4х4 хняВы думете, что вот вышли какие-то там очередные полу планшеты полу дейвайсы и специальный отдел ФБР из 1000-чел садится и начинает их ломать в режиме 24/7 (т к этих недодевайсов выходят тысячи и они еще обновляются)??
Понадобился им какой-то сраный айпад, но сходу за пол часа местные хакеры его не взломали, т к это просто только в кино. Вроде брутфорсили они, это не всегда быстро работает. Но они же власти, у них есть возможность стрясти пароль и так. Ты же по закону не можешь ничего шифровать от властей и должен выдать пароль.
> То то где то тут писалось что фбр не могло разблокировать планшетТак оно и кучку дисков с трукриптом не осилило :). Вообще, а нафиг его разблокировать? Ну пошел да считал микросхемы памяти. То что некоторые слишком тупы для этого еще не отменяет того что это не больно какой способ.
FBI не смогло подобрать пароль только потому, что количество неудачных попыток сильно ограничено. Утверждать, что картинкопароль стоек к подбору только из-за этого - всё равно что утверждать про надёжность PIN-кода из четырёх циферек у кредиток. Для случая неограниченного брутфорса картинко ничем не лучше обычного пароля.
> Это жосский фэйл и равносильно шифрованию цезарем =)
> Так что убейтесь апстену, сударь =)В школьную программу уже включили шифрование цезарем? Прогресс, однако.
> Это чушь.
> В лучшем виде графический ключ представляет собой числовую матрицу.
> В худшем - числовое значение вершины графа.
> Итого если у вас матрица4х4, то если я не ошибаюсь, перебор пройдет
> достаточно быстро =)
> Это жосский фэйл и равносильно шифрованию цезарем =)
> Так что убейтесь апстену, сударь =)Привожу ссылки на статьи по графическому ключу:
http://blogs.msdn.com/b/b8_ru/archive/2011/12/22/signing-pic...
http://blogs.msdn.com/b/b8_ru/archive/2011/12/24/optimizing-...
>blogs.msdn.comИм можно верить?
>>blogs.msdn.com
> Им можно верить?Нет. Верить никому нельзя!
> Привожу ссылки на статьи по графическому ключу:MSDN? Не, спасибо. MS и секурити - то же что китайский автомобиль и безопасность при авариях.
Такие оптимистичные статьи... и ничего не сказано о том, что далеко не любая точка на фото рассматривается как точка интереса, т.е. их набор много, много меньше чем квадратов сетки. Даже на той фотке что в статье точки на носах совершенно очевидны, как и круг вокруг головы. Ещё такими же банальными и частыми будут сиськи =) Короче, грош цена расчётам в статье Всё равно что рассуждать о криптостойкости 6-значного пароля, в то время как в 20% случаев это будет шесть единиц или 123456 или"пароль".
> Это не выход. С появлением сенсорных экранов всё больше распространяется метод проверки
> пароля по графическому ключу.И как ты в общем случае поймешь что это с настоящего сенсорного экрана валится, а не с некоей программной эмуляции?
Кроме того если бы ты не был тупым то прикинул бы число комбинаций и осознал что все эти гламурные понтовые фишки - модно выглядят, но ничего и близко похожего на безопасность не обеспечивают. Так, косят чутка под типа безопасные решения. Но безопасность хуже чем у замка на дипломате с 3 цифрами, которые достаточно просто покрутить 10 минут :).
За последнюю недели угнали базы linkedin, lastfm и LigueOfLegend.
У меня создается впечатление что пароли пользователей лучше вообще у себя не хранить. А ля openid/oauth/brouserid/и тд. Надежнее.
> лучше вообще у себя не хранитьНе ... нафиг нафиг, лучше у себя. Но не пароли а сертификаты. Давно бы уже упростили установку сертификатов в браузер и ходили по сайтам используя сертификаты, через https.
О чем ты говоришь ?! 95% населения не в состоянии запомнить пару логин-пароль. При слове "сертификат" сотрудники нашей бухгалтерии начинают испытывать благоговейный трепет.
Пару? В среднем пользователь интернета зарегистрирован на 5-ти ресурсах. Многие на десятке и более.
И на всех одна и та же пара логин:пароль
> И на всех одна и та же пара логин:парольКоторая забыта после выставления галочки "Сохранить пароль" в браузере
> и ходили по сайтам используя сертификаты, через https.А потом придет Comodo Hacker и выпишет сертификат что он - это вы :)
>> и ходили по сайтам используя сертификаты, через https.
> А потом придет Comodo Hacker и выпишет сертификат что он - это
> вы :)Вы видимо не понимаете разницу между сертификатом сайта и личным сертификатом пользователя.
> Вы видимо не понимаете разницу между сертификатом сайта и личным сертификатом пользователя.Нет, я просто понимаю что достаточно спереть один привкей и после этого все нагибается. А привкей должен быть доступен так или иначе, если новые ключи надо на ходу выкатывать. Бывают конечно смарткарты всякие и прочая, но оно обычно стоит денег, требует кастомных телодвижений, так что на произвольном хостинге не прокатит, да и надежность смарткарты где проц хрен знает чей код и хрен знает как гоняет - штука тоже достаточно абстрактная.
>> Вы видимо не понимаете разницу между сертификатом сайта и личным сертификатом пользователя.
> Нет, я просто понимаю что достаточно спереть один привкей и после этого
> все нагибается. А привкей должен быть доступен так или иначе, если
> новые ключи надо на ходу выкатывать. Бывают конечно смарткарты всякие и
> прочая, но оно обычно стоит денег, требует кастомных телодвижений, так что
> на произвольном хостинге не прокатит, да и надежность смарткарты где проц
> хрен знает чей код и хрен знает как гоняет - штука
> тоже достаточно абстрактная.Видимо все-таки не понимаешь, привкеи тебе придется украсть у каждого из пользователей сайта персонально. Займись.
> Видимо все-таки не понимаешь, привкеи тебе придется украсть у каждого из пользователей
> сайта персонально. Займись.Зачем? Спереть ажно 1 привкей - у ауторити. И все, можно выписать себе 100500 сертификатов на все что угодно. В том числе и других пользователей. Ведь поля сертификата мы можем заполнять как угодно.
На пальцах. Пользователь генерит у себя пару ключ/сертификат. Сертификат засылает на ресурс. Ключ хранит у себя. Никакие ауторити во всем этом не участвуют.
Практически полная аналогия с pgp или авторизацией по ключу в ssh, различаются детали, но не принцип.
>Не ... нафиг нафиг, лучше у себя. Но не пароли а сертификаты. Давно бы уже упростили установку сертификатов в браузер и ходили по сайтам используя сертификаты, через https.В принципе да, любая схема с открытыми ключами вроде OpenPGP намного надежнее, только вэб-стандарта, поддерживаеммого браузерами, под это нет. SSL слишком корявый, избыточный и неудобный и на шаред хостинге не прокатит.
>SSL ... на шаред хостинге..Вы это серьёзно?
Если из поста оставить 4 слова, а остальные заменить точками, то смысл меняется до противоположного. Чудеса!
А в интернет-кафе приходить с блокнотиком, и пол часа набирать сертификат в gedit-е (ну или в notepad-е, смотря какое кафе).
Хотя вообще - мысль здравая, заодно добровольно-принудительный ликбез(ну или отсеивание неосиляторов).
>А в интернет-кафе приходить с блокнотиком, и пол часа набирать сертификат в gedit-е (ну или в notepad-е, смотря какое кафе).Имеете в виду, что юзеры на чужом(общественном) компе наберут свой сертификат с закрытым ключом? о_О
Я опять недооценил изобретательность пользователей, когда речь идет о способности стрелять себе в ногу из любого оружия из любых положений! =)Тем не менее, те кто вводит пароли(тем более экспортирует сертификаты) в интернет-кафе, не должны переживать из-за того, что сайт потерял базу с их паролями. Таких счастливых людей ни наша дискуссия ни любые другие вопросы компьютерной безопасности не беспокоят. =)
> А в интернет-кафе приходить с блокнотиком, и пол часа набирать сертификат в
> gedit-е (ну или в notepad-е, смотря какое кафе).epic win! you are winrar!
> За последнюю недели угнали базы linkedin, lastfm и LigueOfLegend.
> У меня создается впечатление что пароли пользователей лучше вообще у себя не
> хранить. А ля openid/oauth/brouserid/и тд. Надежнее.В linkedin хеши были без пароля, поэтому так легко сломались.
Это огромный минус разработчикам linkedin.С паролями можно делать проще.
Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3.
И пусть ломают.
Даже без соли такой пароль из md5 подобрать сложно и долго.
А сами пароли держать в каком-нибудь менеджере паролей, с очень сильным шифрованием.
Ура ура, назад к бумажкам-стикерам с паролем на мониторах. =)
>> За последнюю недели угнали базы linkedin, lastfm и LigueOfLegend.
>> У меня создается впечатление что пароли пользователей лучше вообще у себя не
>> хранить. А ля openid/oauth/brouserid/и тд. Надежнее.
> В linkedin хеши были без пароля, поэтому так легко сломались.
> Это огромный минус разработчикам linkedin.
> С паролями можно делать проще.
> Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3.
> И пусть ломают.
> Даже без соли такой пароль из md5 подобрать сложно и долго.
> А сами пароли держать в каком-нибудь менеджере паролей, с очень сильным шифрованием.Расскажи-ка мне друг, каким по твоему образом сервер должен проверять пароль пользователя, если хеш от него зашифрован ? Зачем писать откровенную глупость, если совершенно не понимаешь о чем вообще идет речь ?
>[оверквотинг удален]
>>> хранить. А ля openid/oauth/brouserid/и тд. Надежнее.
>> В linkedin хеши были без пароля, поэтому так легко сломались.
>> Это огромный минус разработчикам linkedin.
>> С паролями можно делать проще.
>> Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3.
>> И пусть ломают.
>> Даже без соли такой пароль из md5 подобрать сложно и долго.
>> А сами пароли держать в каком-нибудь менеджере паролей, с очень сильным шифрованием.
> Расскажи-ка мне друг, каким по твоему образом сервер должен проверять пароль пользователя,
> если хеш от него зашифрован ?а где и кем предлагалось шифровать хеши?
>[оверквотинг удален]
>>> В linkedin хеши были без пароля, поэтому так легко сломались.
>>> Это огромный минус разработчикам linkedin.
>>> С паролями можно делать проще.
>>> Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3.
>>> И пусть ломают.
>>> Даже без соли такой пароль из md5 подобрать сложно и долго.
>>> А сами пароли держать в каком-нибудь менеджере паролей, с очень сильным шифрованием.
>> Расскажи-ка мне друг, каким по твоему образом сервер должен проверять пароль пользователя,
>> если хеш от него зашифрован ?
> а где и кем предлагалось шифровать хеши?А ты бы как интерпретировал фразу "В linkedin хеши были без пароля, поэтому так легко сломались." ? А "А сами пароли держать в каком-нибудь менеджере паролей, с очень сильным шифрованием." ?
> А ты бы как интерпретировал фразу "В linkedin хеши были без пароля,
> поэтому так легко сломались." ? А "А сами пароли держать в
> каком-нибудь менеджере паролей, с очень сильным шифрованием." ?ну ведь ясно же что говорится о соли, описался человек, зачем сразу с кулаками?
>> А ты бы как интерпретировал фразу "В linkedin хеши были без пароля,
>> поэтому так легко сломались." ? А "А сами пароли держать в
>> каком-нибудь менеджере паролей, с очень сильным шифрованием." ?
> ну ведь ясно же что говорится о соли, описался человек, зачем сразу
> с кулаками?Ясно ? А что тогда означает вот эта фраза: "Даже без соли такой пароль из md5 подобрать сложно и долго." ?
Ясно, что человек вообще не понимает о чем пишет. На что я ему и пытаюсь намекнуть. Кстати, а я не с автором этого поста общаюсь ?! ;)
>>> А ты бы как интерпретировал фразу "В linkedin хеши были без пароля,
>>> поэтому так легко сломались." ? А "А сами пароли держать в
>>> каком-нибудь менеджере паролей, с очень сильным шифрованием." ?
>> ну ведь ясно же что говорится о соли, описался человек, зачем сразу
>> с кулаками?
> Ясно ? А что тогда означает вот эта фраза: "Даже без соли
> такой пароль из md5 подобрать сложно и долго." ?
> Ясно, что человек вообще не понимает о чем пишет. На что я
> ему и пытаюсь намекнуть. Кстати, а я не с автором этого
> поста общаюсь ?! ;)Нет, не с автором.
Блин, ну вы действительно напрягите уже извилины, совет на форуме вам был дан правильный.
Читаем: "Даже без соли такой пароль из md5 подобрать сложно и долго.", задаемся вопросом, какой "такой", идем чуть выше и видим: "Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3"
>[оверквотинг удален]
>> такой пароль из md5 подобрать сложно и долго." ?
>> Ясно, что человек вообще не понимает о чем пишет. На что я
>> ему и пытаюсь намекнуть. Кстати, а я не с автором этого
>> поста общаюсь ?! ;)
> Нет, не с автором.
> Блин, ну вы действительно напрягите уже извилины, совет на форуме вам был
> дан правильный.
> Читаем: "Даже без соли такой пароль из md5 подобрать сложно и долго.",
> задаемся вопросом, какой "такой", идем чуть выше и видим: "Использовать 32
> симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3"Все, ты меня убедил. Я точно дурак.
Спасибо)
> Использовать 32 симольный рандомный пароль, типа 2AsVAVCrZtiUKXNLwBGgL8PFBseGnGp3.
> И пусть ломают.
> Даже без соли такой пароль из md5 подобрать сложно и долго.Совсем не факт. К этому паролю может быть трёхсимвольная коллизия. Соль должна быть обязательно.
>> Даже без соли такой пароль из md5 подобрать сложно и долго.
> Совсем не факт. К этому паролю может быть трёхсимвольная коллизия.Вот этого вообще практически никто не понимает.
Вся затея об увеличении количества символов в пароле -- НИЧТО, если они хранятся в "коротком" хэше.
Для тех, кто не в курсе: после анализа стойкость MD5 к коллизиям -- ~2^80. Пароль длинее, чем в 10 символов, можете не ставить -- к ЛЮБОМУ паролю по принципу Дирихле будет существовать коллизия не длиннее, чем в 10 символов.
> Соль должна быть обязательно.
А вот это fail, тов. собеседник. :) Ну КАК salt спасёт от hash collision?
Salt -- это от паролей типа 12345678. Если без соли -- вы берёте ГОТОВЫЕ ХЭШИ самых популярных паролей и сравниваете MD5 из password-файла с этими ГОТОВЫМИ ХЭШАМИ. Пароли подбираются быстро и просто. Наличие salt'ов эту дырку закрывает -- готовых хэшей должно быть в 2^(длина соли в битах) раз больше, а ОЗУ -- оно, знаете ли, не резиновое.Но от hash-коллизий это всё равно не спасает. Salt, скажем, в случае /etc/master.passwd лежит рядышком с криптограммой. Ну, надо будет считать не MD5(i), а MD5(salt*i), делов-то.
>А вот это fail, тов. собеседник. :) Ну КАК salt спасёт от hash collision?md5($pass + $salt) = hash ну нашли вы коллизию положим, какой пароль вводить? Как вы пароль узнаете? А если соль более 30 символов а ваши коллизии все "по принципу дирихле"
по десять - то какой с них толк?
В вашей терминологии это будет $pass. Его и вводить.
(Я правильно понимаю, что речь идёт про поиск любого такого пароля, который при обработке хеш-функцией даёт заданный хеш и, при этом, исходный пароль мы не знам?)При солёных хешах поиск сводится к поиску такого пароля P* (при исходном пароле P), что:
H(S . P) == H(S . P*),
где H - хеш-функция, S - соль, "." - конкатенация.То есть злоумышленник, зная соль, функцию и хеш, должен найти такой пароль, который после конкатенации и обработки функцией H даёт прежний хеш.
Как по мне - это сильно усложняет задачу по сравнению с нахождением коллизии типа:
H(P) == H(P*).---
Да и вообще, когда P неизвестен, но известен H(P) - это, вроде, называется поиском прообраза (и сложность именно этой операции важна, если утекли хеши). А поиск коллизии - это просто поиск _любой_ пары P и P*, дающих одинаковый хеш.
Впрочем, я могу быть не прав...
В общем случае соль тоже не известна.
Если соль известна то она может быть достаточно большой что бы отмести все возможные короткие(читай известные, читай таблицы) колизии.
Чаще всего соль лежит там же, где и хеш.
> В вашей терминологии это будет $pass. Его и вводить.Но подобрана-то коллизия на $pass + $salt.
в моей терминологии это будет
md5(коллизия) = хеш
md5(пасс+соль)= хеш //тот же
Вы знаете коллизию - найдите мне пас, если соль неизвестна.
Или если соль известна.
> Для тех, кто не в курсе: после анализа стойкость MD5 к коллизиям
> -- ~2^80. Пароль длинее, чем в 10 символов, можете не ставить
> -- к ЛЮБОМУ паролю по принципу Дирихле будет существовать коллизия не
> длиннее, чем в 10 символов.Ну, это не совсем верно. Дело в том что 2^80 операций даже на CPU - это дохрена, мягко говоря - 38 млн лет поиска при 1 млрд хеш/сек - тут никакой кластер не поможет.
Ну и 2^80 операций соответсвует где то 16 ти символьному буквенноцифровому паролю (без спецсимволов).
Хотя конечно согласен что пароли хешировать MD5 в 2012 году не стоит - есть гораздо более лучшие функции.
Начали вы верно, но немного запутались.предположим
crypt(salt0+pass0) == hash
но также
crypt(collision) == hash
Если collision начинается с slat0, то ДА - это не коллизия
и вы нашли пароль, или очень удачную коллизию
pass1 = collision[len(salt0):]
но вероятность того, что
crypt(salt0+pass0) == crypt(salt0+pass1)
тем меньше, чем длиннее соль.
И если для любого пароля длиной 10 символов существует коллизия длиной < 10 символов, то достаточно соли в 8-10 рандомных символов чтоб сильно усложнить возможность поиска коллизий, и(или) использование словаря.
Ну и стандартная причина ИСПОЛЬЗОВАТЬ соль - в силу [s]стадного[/s] человеческого фактора - из 1000 человек пароль совпадет допустим у 3% человек, а значит 30 хешей будут одинаковыми, и скорее всего из словаря(к которому скорее всего уже существует таблица хэшей). С солью - все эти хэши будут уникальными.
> В linkedin хеши были без пароля, поэтому так легко сломались.Я имел в виду "без соли".
Сорри, если вызвал у кого диссонанс с реальностью)
> За последнюю недели угнали базы linkedin, lastfm и LigueOfLegend.
> У меня создается впечатление что пароли пользователей лучше вообще у себя не
> хранить. А ля openid/oauth/brouserid/и тд. Надежнее.Не надо хранить никакую важную инфу в интернете вообще. Никаким сайтам просто нельзя доверять.
На более чем половине сайтов нужно отказаться от паролей вообще, как сдесь.
Зачем мне помнить пароль чтобы раз в день зайти пофлудить или че-то скачать? Нелепые ограничения чтоб привязать пользователя, а потом угрожать баном (контролировать), и получить мишень для спама.
> Зачем мне помнить пароль...ради ответа на нить и крутой аватарки возле вашего ответа ))
> Нелепые ограничения чтоб привязать пользователя, а потом угрожать баномвы таки не поверите - банить можно и по IP
* ради оповещения на мыло об ответе на нить и ...
> * ради оповещения на мыло об ответе на нить и ...На этом сайте оповещения об ответе можно получать и не регистрируясь.
>> * ради оповещения на мыло об ответе на нить и ...
> На этом сайте оповещения об ответе можно получать и не регистрируясь.зато без регистрации нельзя прекратить их получать. что открывает широкие возможности заваливать одноклассников спамом с опеннета.
http://www.openwall.com/articles/PHP-Users-Passwords
"собственный модифицированный алгоритм" вот этого пожалуйста поменьше))
Я слашал SHA тоже не панацея...
Ога, security by obscurity
+1
Шнайер писал, что сожалеет о выпуске своей первой книги по криптографии, потому что куча народу по ее прочтении возомнила себя великими криптографами и начала писать бестолковые алгоритмы, ломаемые на раз. В криптографии, если не являешься экспертом, никогда не помешает быть консервативным и применять максимально проверенные временем методики безо всякой самодеятельности
В целом всё так, текст новости здесь соответствует оригиналу, и мнение такого уважаемого человека знать интересно, но:1. Советы - спорные. По-моему, части из них лучше не следовать. ;-)
2. За пару дней при миллионе проверок в секунду подбирается всё-таки не любой восьмисимвольный пароль, а лишь любой восмьмибуквенный (латинские буквы одного регистра). И это при атаке на один конкретный salt, а не на всю базу. По сути, впрочем, это ситуации не меняет - типичные пароли подбираются намного быстрее случайных (даже если набор возможных символов больше), и, говоря об offline-атаках, пароли (или лучше фразы) должны быть сложнее, а md5crypt - действительно устарел. (В некотором смысле, он был устаревшим уже на момент создания, т.к. настраиваемое количество итераций уже было реализовано чуть раньше в BSDi BSD/OS и в свободной реализации FreeSec, предложенной для NetBSD в 1994-м году. Конкретно DES в FreeBSD использовать не стали бы, но опыт перенять могли бы.)
<plug>
Я буквально на прошлой неделе делал презентацию на схожую тему на PHDays (кстати, зря на OpenNet не было новости о PHDays). Я там тоже даю советы. ;-) Но спорные я стараюсь так и называть, и это не советы авторам отдельных программ или админам отдельных сайтов, а материал для дискуссии в сообществе. Последним слайдом я как раз предостерегаю от создания каждым своего метода хеширования - т.е. совет, противоположный тому, что дает phk.Вот мои слайды:
http://www.openwall.com/presentations/PHDays2012-Password-Se.../Здесь есть видео ("День второй. Трансляция из конференц-зала", 13:59):
http://digitaloctober.ru/event/positive_hack_daysНа PHDays было много другого интересного - например, Sylvain Munaut демонстрировал превращение телефона в базовую станцию (9:11 утра там же) - и это только один пример.
</plug>
> 2. За пару дней при миллионе проверок в секундустобаксовый AMDшный GPU крушит порядка 80 миллионов SHA1 в секунду...
А теперь прикинь: http://ck.kolivas.org/pictures/Mining/IMG_1240.JPG (Кон Коливас и его майнер биткоинов - 4x6990). Я даже представить себе боюсь сколько оно осиливает. Но могу предположить что близко к миллиарду. А теперь прикинь - отдельные маньяки ставят штук 20 таких системников где-нибудь. И они даже не являются датацентром. Так, чуваки с несколько k$ в кармане решившие подзаработать на скоростных вычислениях.
> 2. За пару дней при миллионе проверок в секунду подбирается всё-таки не
> любой восьмисимвольный пароль, а лишь любой восмьмибуквенный (латинские буквы одного регистра).ну и проверки давно уже больше 1М на большинство алгоритмов: http://hashcat.net/oclhashcat-plus/
> http://hashcat.net/oclhashcat-plus/Q) Will the source be published?
A) No.Кхе-кхе, запускать неизвестный бинарь делающий фиг знает что для взлома паролей? Этак можно нарваться на то что взломают взломщика. Если уж на то пошло, есть hashkill с исходниками.
все равно никто исходники смотреть не будет.
К тому же можно проверить антивирусом и запускать в песочнице
о, практически эталонный пост на тему «как понимает безопасность обычный юзер».
> 2. За пару дней при миллионе проверок в секунду подбирается всё-таки не
> любой восьмисимвольный пароль, а лишь любой восмьмибуквенный (латинские буквы одного регистра).Ну Камп все таки говорил про md5crypt, там жеж 1000кратное хеширование MD5. Просто MD5 можно чуть поболе миллиарда в секунду щас на топовых GPU колбасит. :)
Хотя совет изобретать свой алгоритм весьма странен конечно...
Спасибо, Александр, очень интересный и познавательный доклад.
> базирующийся на стойких хэшах, таких как SHAАга, а он видел 100-долларовые GPU перебирающие 200 миллионов SHA-256 в секунду? :)
Ну короче, пароль минимум 15 символов и ни в коем случае не из словарных слов :)
Длинный пароль ничем не поможет. Чем длиннее пароль чем больше шанс коллизий. И чем больше угнали паролей тем больше шанс взлома. Причем не линейно - Парадокс дней рождения.
Пока размер хеша больше размера пароля - вероятность коллизий крайне низка. (При "хорошей" хеш-функции, конечно)
еще раз повторяю - Парадокс дней рождения.
Обоснуй.
ещё какие парадоксы знаешь ?
Еще знаю "парадокс скобок".Это когда люди считают, что употребление непарных скобочек вне математических выражений делает их умнее, пропорционально количеству скобочек. Но как обычно и бывает в парадоксах это только самообман и в реальности все с точностью до наоборот.
> еще раз повторяю - Парадокс дней рождения.Парадокс дней рождения для подбора пароля по конкретному хэшу роли не играет.
> И чем больше угнали паролей тем больше шанс взлома. Причем не линейно - Парадокс дней рождения.По-твоему, вероятность выпадения двух шестерок в костях равна 32.6%, а не 16.1% как утверждает товарищ Бернулля?
>> И чем больше угнали паролей тем больше шанс взлома. Причем не линейно - Парадокс дней рождения.
> По-твоему, вероятность выпадения двух шестерок в костях равна 32.6%, а не 16.1%
> как утверждает товарищ Бернулля?Про дни рождения - это немного о другом. Это вероятность выпадения двух одинаковых цифр при увеличении количества одновременно бросаемых костей. Две кости - маловероятно, три кости - более вероятно и т.п. Но вспомнили не к месту.
Он это вспомнил к поиску коллизий. Если ищется просто любая пара паролей, дающих один хеш на выходе, то, действительно, сложность будет 2^(n/2), а не 2^n при хеше n-ой разрядности (2^n возможных выходных значений). Это и есть парадокс дней рождения.При хранении паролей в хешированном виде и в случае утечки хешей это не играет роли.
> Длинный пароль ничем не поможет.Поможет.
> Чем длиннее пароль чем больше шанс коллизий.
Шанс коллизий зависит лишь от числа попыток и числа хешей, если алгоритм не совсем отстой. Правда вот выиграть в лотерею вида N из 2^160 (окей, 2^159 с учетом парадокса близнецов) - ну как бы удачи, с любым N которое вы осилите, даже с пачкой GPU ;).
Дело в том что 2^160 это настолько дофига что например миллиард - это очень незначительная часть от этого числа :). Более того, миллиард перебранных хешей * миллион секунд (более 10 дней) * 1000 GPU - все еще по прежнему очень небольшая часть от этого числа.
> И чем больше угнали паролей тем больше шанс взлома. Причем не линейно
Шанс взлома "какого нибудь из паролей" - да. В основном за счет того что у кого-то окажется тупой, короткий или словарный пароль. А так - чистая такая лотерейка вида N из 2^160 (или сколько там битов в хеше). Если пароль выбран не халтурно, 2^160 вполне хватит чтобы даже на куче GPU шанс найти совпадение был небольшой. Хотя особые эстеты могут взять 2^256 (SHA-256 например). Угадывать станет совсем беспонтово. Только вот пароль должен быть сложный и не словарный. Иначе, пардон, все просто посчитают sha от словариков и простых сочетаний и увидят что ага - вот оно, совпадает с вон тем хешом.
> - Парадокс дней рождения.
Вот только он никак не помогает взломать конкретный хэш, ну, кроме снижения в среднем на 1 бит множества перебора. А вас сильно большая разница: 2^159 или 2^160? Оно конечно в 2 раза, но оба числа одинаково космические для практической цели перебрать весь диапазон :)
> (окей, 2^159 с учетом парадокса близнецов)
> ну, кроме снижения в среднем на 1 бит множества перебора. А вас сильно большая разница: 2^159 или 2^160?2^80
RTFM
>Пол-Хенинг Камп порекомендовал использовать собственный модифицированный алгоритм, базирующийся на стойких хэшахБудем считать, что автор имел в виду совместное использование нескольких проверенных алгоритмов, а не то, что я сначала подумал. Иначе мне страшно. %)
