В рамках конкурса Password Hashing Competition (https://password-hashing.net/) (PHC) предпринята попытка выявления новых схем хэширования паролей с целью стимулирования задействования надёжных схем защиты паролей. Текущее состояние (http://www.openwall.com/presentations/Passwords12-The-Future... в области защиты паролей оценивается как неприемлемое - web-сервисы зачастую хранят пароли пользователей в открытом виде или применяют ненадёжные методы хэширования, такие как MD5 или SHA-1, для которых разработаны эффективные методы подбора паролей.
Из стандартов формирования ключей на основе паролей доступен только PBKDF2 (http://ru.wikipedia.org/wiki/PBKDF2) (PKCS#5, NIST SP 800-132), а из альтернативных реализаций выделились только bcrypt (http://en.wikipedia.org/wiki/Bcrypt) и scrypt (http://www.tarsnap.com/scrypt.html). В сообществе витают идеи по созданию новых методов хэширования, но они имеют разрозненный и случайных характер. Конкурс PHC призван увлечь заинтересованных лиц и придать их работам востребованный и осмысленный характер.
Методы проведения конкурса построены на основе принципов (http://competitions.cr.yp.to/), применяемых в таких криптографических конкурсах, как AES, eSTREAM и SHA-3. Работы для участия будут приниматься до 31 января 2014 года, после чего начнётся этап анализа предложенных работ и выявления наиболее оптимальных решений. В третьем квартале 2014 года будут объявлены финалисты из которых до второго квартала 2015 года планируется выделить одного или нескольких победителей.
Из технических требований (https://password-hashing.net/call.html) к выставляемым на конкурс работам отмечается как минимум поддержка хэширования паролей размером от 0 до 128 символов, использование 16-байтового salt и наличие возможности регулирования параметров работы алгоритма с точки зрения скорости работы и размера хэша. Эталонные реализации должны быть подготовлены на языке C или C++, допускается использование стандартных функций библиотеки libcrypto (например, реализаций AES или SHA-256). Методы не должны покрываться запатентованными технологиями и должны распространяться без ограничений и на условиях не требующих выплаты отчислений.
В качестве критериев оценки отмечается:
- Безопасность: стойкость к коллизиям, случайно выглядящий вывод, невозможность обратного преобразования, невозможность получения сведений о характере пароля через анализ хэша, противостояние методам перебора, трудность распараллеливания подбора, стойкость к акселерации подбора с использованием ASIC, FPGA и GPU;
- Простота: общая ясность схемы, простота реализации (с позиции кодирования, тестирования, отладки и интеграции), минимум привязки к внешним примитивам или конструкциям;- Функциональность: эффективность с позиции тюнинга параметров работы, возможность изменения параметров (скорость и размер) для существующего хэша без наличия пароля.
URL: https://password-hashing.net
Новость: http://www.opennet.me/opennews/art.shtml?num=36118
Интересно, кто предложит лучший вариант? Может россияне отличатся на этот раз.
Россияне уже отличалтсь, ГОСТ-овский (не помню номер) метод хэширования давно считается гораздо лучше MD5.
И чем он лучше?
чем MD5
Смешно, но это не так. См криптоанализ Менделя (и др.) от 2008 г.
В сравнении с MD5 сейчас всё что угодно лучше =) Там и коллизий найдено. Там и либы построены для ломания на GPU. Думаю, можно надыбать даже пару сотен гигов таблиц =)
> Может россияне отличатся на этот раз.Даешь ГОСТ Р 34.11-2014
Вам не все равно из какой страны предложат лучший вариант?
Нет, мне не всё равно. А тебе ?
Племенное мышление во всей красе
Забугорное мышление космополита во всей красе.
Мышление метрополита не может быть внутри- или забугорным ;-)
Прошу прощения, а какже blowfish twofish
Просмотри хоть бегло любой учебник по криптографии.
википедии хватило чтобы понять что это не хеш-функции, а криптофункции.
Ну, DES, какбэ, тоже не хэш, и ничего, столько лет использовали в UNIX'овом crypt() (сиречь, passwd) без всяких проблем.
Не надо путать "DES-блочный шифр" и "DES-хеш" на основе "DES-блочного шифра".
ЕМНИП, из любого блочного шифра можно получить криптографическую хэш-функцию.Правда не все будут качественными.
> Текущее состояние в области защиты паролей оценивается как неприемлемое - web-сервисы зачастую хранят пароли пользователей в открытом видеони наверно думают, что как только разработают новые методы хеширования, все эти веб-сервисы волшебным способом перестанут использовать старые способы хранения паролей и начнут использовать новые
См. первый вопрос/ответ в FAQ:
https://password-hashing.net/faq.htmlА также мой подробный ответ в r/crypto:
http://www.reddit.com/r/crypto/comments/18j6m8/password_hash...
лечить такое наверно можно только предоставлением функционала из коробки в языке...
и бейсбольной битой по рукам...
Откуда такая уверенность, что пароли для веб сервисов хранятся в открытом виде.
А уверенность это основана на таком казалось бы пустяшном факте - как не умыкнут базу с паролями, так они все не зашифрованные :-)
Практически во всех местах с регистрацией есть функция восстановления забытого пароля. Где-то при использовании данной возможности генерируют новый пароль, но многие сайты просто присылают старый. Как вы думаете, они его из при помощи сильного колдунства получают или все-таки хранят в открытом виде?
> Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
> Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
> просто присылают старый. Как вы думаете, они его из при помощи
> сильного колдунства получают или все-таки хранят в открытом виде?С таким же успехом, можно использовать самый хороший дверной замок, и при этом не закрывать его. Кто-то не использует шифрование паролей, но это же не говорит о том, что это, потому что алгоритм плахой.
плОхой.
если замок лежит на полочке, то закрывать его бессмысленно.
Вообще лично я такое довольно редко видел. Обычно просят указать новый пароль.
Первое время на вконтактике высылали старый пароль на почту.
> Первое время на вконтактике высылали старый пароль на почту./me фейспальмирует
Контактик помнит скомпрометироанные пароли, такая штука.
> Контактик помнит скомпрометироанные пароли, такая штука.может он помнит не пароли а хеши?
> Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
> Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
> просто присылают старый. Как вы думаете, они его из при помощи
> сильного колдунства получают или все-таки хранят в открытом виде?Ну не совсем в открытом. Это же не файловое хранилище одного известного отечественного сервиса. Хранится, вернее всего, в базе данных MySQL, в зашифрованном виде, причем к базе доступ есть только с localhost. Забраться не так уж легко.
Ну обычно и ломают приложение, а не mysql...
>>технических требований к выставляемым на конкурс работам отмечается как минимум поддержка хэширования паролей размером от 0 до 128 символовЭто уже не пароль слово.а пароль фраза подобрать которую будет гораздо проще.
Пора делать массовое внедрение смарткарт или в качестве костыля выпустить стандарт на флешку,на которой будет хранится пароль.
Шифровать флешку целиком или только файл с паролем не знаю.
etoken, rutoken и прочие....
> etoken, rutoken и прочие....Верно, говорите, есть веб сервисы, которые вообще по отпечатку пальца работают, и давно забыли уже о паролях. Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков. Сразу сканер шел от производителя, бук не работал без отпечатка, Этим же сканером можно было пользоваться и в других сервисах.
И как это поможет для web? В чем разница хранить пароль или скан отпечатка пальца?
> Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков.Ах вот оно что, а я-то думал, что это для аутентификации юзера непосредственно на буке (ну или где там сложили образцовые отпечатки при тренировке, помимо полированной мебели).
Но теперь мы с двумя thinkpad'ами будем знать, что они на самом деле без fprintd не работали.
Скачивал я как-то SDK для etoken-ов. Там вместо метровой библиотечки и пары примеров - гигабайта полтора какого-то неструктурированного непортируемого хлама, в котором можно закопаться на месяц. Пол дня посмотрел и плюнул. Не хотят они, чтобы их использовали.
а вот интересно, появится ли алгоритм с челенжом где на сервере не будет храниться пароль открытым текстом? Например, как это делается в несимметричном ключе.
Если я правильно понял вопрос, то такие уже есть. RFC 5802 (SCRAM) и еще:
http://openwall.info/wiki/people/solar/algorithms/challenge-...
> а вот интересно, появится ли алгоритм с челенжом где на сервере не
> будет храниться пароль открытым текстом? Например, как это делается в
> несимметричном ключе.Тот же SRP, например: https://en.wikipedia.org/wiki/Secure_remote_password_protocol
А почему такая уверенность что кто-то что-то вообще пришлет ?
>трудность распараллеливания подбораЭто вообще как?
Что мешает пробовать пароли на букву А на одной машине, на Б на другой? Операция подбора параллельна сама по себе.
>>трудность распараллеливания подбора
> Это вообще как?
> Что мешает пробовать пароли на букву А на одной машине, на Б
> на другой? Операция подбора параллельна сама по себену можно тайм-аут сделать минут 15 после неправильного ввода пароля. Неудобство для пользователя, конечно, но, во-первых, это стимулирует использование утилит - связок ключей, а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будет.
> а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будетСкорее поменяет пароль на трехбуквенный, в котором не ошибешься
god, sex, х..
Ага-ага, застопорит разработку брутфорс-механизма в лучшем случае на 10 минут.
Система должна быть открытой, а значит легко будет отследить func(delay) и остается стащить хеш или подменить уже модифицированный бинарник c delay = 0;
не путайте специфику работы алгоритма и системы, которая использует этот алгоритм нужным ей образом.под подбором в данном случае понимается просто подбор данных под известный злоумышленнику хэш (локально), а не обращение к какой-то удаленной системе, которая проверяет пароли и в случае неправильности блокирует систему. Зачем, имея на руках хэши, перебирать пароли на удаленной системе? Ведь конкурс заявлен просто на алгоритм, а не какой-нибудь сервер а-ля керберос или библиотеки PAM-аутентификации. Аутентификационные сервисы, конечно, могут придумывать разные приемчики типа таймаутов и блокировок, уровни сложности паролей или расписания, когда пользователь может работать в системе, но это не имеет никакого отношения к алгоритмам хэширования (приемчикам манипулирования с массивами байт). Хэширование не имеет никакого отношения к протоколам взаимодействия программных комплексов, это протоколы в своей работе на разных этапах могут использовать алгоритмы хэширования.
Лучше бы придумали надежного приемника MSCHAPv2, т.е. когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам сервер. За это люди реально скажут *огромное* спасибо и с радостью включат в будущие стандарты.http://deployingradius.com/documents/protocols/compatibility... - Табличка, демонстрирующая проблему на примере радиуса и WPA-Enterprise (хотя можно тоже самое нарисать и для SMTP AUTH, IMAP4, etc, etc):
В целом впечатления от новости -- обострение NIH-синдрома.
> когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам серверВы из анабиоза восстали что-ли ? Вашим условиям даже древний CRAM-MD5 удовлетворяет.
Бред сивой кобылы.
CRAM-MD5 -- это тот дырявый алгоритм, который или требует plaintext пароля на сервере, или же промежуточный md5-хеш в базе + специально модифицированный сервер, который пользуется этим промежуточных хешем. В результате, угон или пароля или его хеша позволяет успешно проходить CRAM-MD5 аутентификацию.
Следующий!
А ничего что угон NTLM хеша, используемого в вашем любимом MSCHAPv2, приводит ровно к тому же результату ?Не говоря уже о том что NTLM хеш сам по себе ископаемое убожество.
> Лучше бы придумали надежного приемника MSCHAPv2Да придумано все, и очень давно. EAP-TLS, пароли не нужны.
Только заставьте теперь дедушку Ляо это в роутеры запихать.
Боюсь показаться КЭПом, но конкурс направлен на реализацию системы управления ключами. ИМХО, недавно завершился конкурс хеш-функции на звание SHA-3 и есть достаточно хорошие twofish, aes, serpent блочные шифры.
Нужен лишь механизм, как эти управлять (правильно организовать генерацию соли, правильный механизм раздутия области хранения инфы, учитывать тип носителя информации и тому подобное) ;-)PS: на языке оригинала, как-то все прозрачней и понятней о чем речь, чем перевод.
>...такие как MD5 или SHA-1...Почему все всегда говоря о хэшировании паролей упоминают сразу эти алгоритмы, принимая их за эталонные. и вываливают их недостатки?
Про sha512 никто не слышал что ли?
А в чем плох метод хранения с солью хэша SHA-2, полученного на основе хэша SHA-2 от пароля ? Словарный перебор как понимаю исключается, а на полный перебор несколько лет понадобится. Или есть какой-то подвох и современные GPU позволяют свести время такого перебора до дней/месяцев ?
Даже md5 с солью вполне достаточно, но 99% просто хранят md5(pass)
Нет, недостаточно.
С чего это вдруг словарный перебор исключается?! Не исключается он. Это первое.Второе. Солёный sha2 - это, конечно, хорошо, Но:
Конкурс направлен не столько на разработку хеш-функции, сколько на систему, использующую в основе хеш-функцию, и предназначенную для безопасного хранения паролей.И эта система должна обеспечивать: применимость к данным довольно большого развмера (до 128 байт), использование соли с большой энтропией, желательно опциональное использование local-parameter (как вторая "соль"), уникального, например для сервера. Очень хотелось бы, что б функция не была сильно эффективна на gpu, fpga etc - для того, что б заведомо не давать атакующему фору (а тот же sha2 двольно быстр на gpu).
Также требуется возможность тюнинга - настраиваемное "CPU-hardness" (например через число раундов стретчинга, хотя, возможно, есть и другие варианты), "memory-hardness" (если используется). Кроме того, неплохо было бы обеспечить регулирование последних двух для уже посчитанных хешей, не зная при этом паролей.
Разумеется, нужно придумать удобный формат представления таких хешей, обеспечив портабельность и однозначность ...
И это далеко не всё, что требуется.
Исходя из всего этого, мне что-то не кажется, что удачные схемы для целей храниения паролей в данный момент существуют.
Что-то коммент в сторону ушёл, ну да ладно.