The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Инициатива по разработке новых методов хэширования паролей

16.02.2013 22:35

В рамках конкурса Password Hashing Competition (PHC) предпринята попытка выявления новых схем хэширования паролей с целью стимулирования задействования надёжных схем защиты паролей. Текущее состояние в области защиты паролей оценивается как неприемлемое - web-сервисы зачастую хранят пароли пользователей в открытом виде или применяют ненадёжные методы хэширования, такие как MD5 или SHA-1, для которых разработаны эффективные методы подбора паролей.

Из стандартов формирования ключей на основе паролей доступен только PBKDF2 (PKCS#5, NIST SP 800-132), а из альтернативных реализаций выделились только bcrypt и scrypt. Указанные системы не лишены недостатков и в сообществе витают идеи по созданию новых методов хэширования, но подобные инициативы имеют разрозненный и случайных характер. Конкурс PHC призван увлечь заинтересованных лиц и придать их работам востребованный и осмысленный характер.

Методы проведения конкурса построены на основе принципов, применяемых в таких криптографических конкурсах, как AES, eSTREAM и SHA-3. Работы для участия будут приниматься до 31 января 2014 года, после чего начнётся этап анализа предложенных работ и выявления наиболее оптимальных решений. В третьем квартале 2014 года будут объявлены финалисты из которых до второго квартала 2015 года планируется выделить одного или нескольких победителей.

Из технических требований к выставляемым на конкурс работам отмечается как минимум поддержка хэширования паролей размером от 0 до 128 символов, использование 16-байтового salt и наличие возможности регулирования параметров работы алгоритма с точки зрения скорости работы и расхода памяти. Эталонные реализации должны быть подготовлены на языке C или C++, допускается использование стандартных функций библиотеки libcrypto (например, реализаций AES или SHA-256). Методы не должны покрываться запатентованными технологиями и должны распространяться без ограничений и на условиях не требующих выплаты отчислений.

В качестве критериев оценки отмечается:

  • Безопасность: стойкость к коллизиям, случайно выглядящий вывод, невозможность обратного преобразования, невозможность получения сведений о характере пароля через анализ хэша, противостояние методам перебора, трудность распараллеливания подбора, стойкость к акселерации подбора с использованием ASIC, FPGA и GPU;
  • Простота: общая ясность схемы, простота реализации (с позиции кодирования, тестирования, отладки и интеграции), минимум привязки к внешним примитивам или конструкциям;
  • Функциональность: эффективность с позиции тюнинга параметров работы, возможность изменения параметров (скорость работы и расход памяти) для существующего хэша без наличия пароля.


  1. Главная ссылка к новости (https://password-hashing.net...)
  2. OpenNews: Оценка эффективности хэширования паролей на крупном GPU-кластере
  3. OpenNews: Автор md5crypt подчеркнул небезопасность данного алгоритма и призвал перейти на более стойкие методы хэширования паролей
  4. OpenNews: Представлена хеш-функция BLAKE2, претендующая на роль высокопроизводительной замены MD5 и SHA1
  5. OpenNews: Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)
  6. OpenNews: Выбран финальный алгоритм для SHA-3
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/36118-crypt
Ключевые слова: crypt, hash, security, password
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (60) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, AnonuS (?), 23:23, 16/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Интересно, кто предложит лучший вариант? Может россияне отличатся на этот раз.
     
     
  • 2.2, Онаним (?), 23:31, 16/02/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Россияне уже отличалтсь, ГОСТ-овский (не помню номер) метод хэширования давно считается гораздо лучше MD5.
     
     
  • 3.6, sdfsfsf (?), 00:15, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И чем он лучше?
     
     
  • 4.51, Аноним (-), 17:37, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    чем MD5
     
     
  • 5.58, sdfsfsf (?), 21:06, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Смешно, но это не так. См криптоанализ Менделя (и др.) от 2008 г.
     
  • 3.7, Fufyrka (?), 01:01, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В сравнении с MD5 сейчас всё что угодно лучше =) Там и коллизий найдено. Там и либы построены для ломания на GPU. Думаю, можно надыбать даже пару сотен гигов таблиц =)
     
  • 2.3, BoVe (?), 23:35, 16/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Может россияне отличатся на этот раз.

    Даешь ГОСТ Р 34.11-2014

     
  • 2.26, фыфа (?), 13:48, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вам не все равно из какой страны предложат лучший вариант?
     
     
  • 3.41, AnonuS (?), 01:11, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет, мне не всё равно. А тебе ?
     
     
  • 4.53, Crazy Alex (ok), 18:31, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Племенное мышление во всей красе
     
     
  • 5.62, AnonuS (?), 03:35, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Забугорное мышление космополита во всей красе.
     
     
  • 6.63, pilat (ok), 17:53, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Мышление метрополита не может быть внутри- или забугорным ;-)
     

  • 1.4, Аноним (-), 23:45, 16/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прошу прощения, а какже blowfish twofish
     
     
  • 2.31, Аноним (-), 19:09, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Просмотри хоть бегло любой учебник по криптографии.
     
     
  • 3.48, Аноним (-), 11:58, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    википедии хватило чтобы понять что это не хеш-функции, а криптофункции.
     
     
  • 4.54, Мимо ракодил (?), 18:34, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, DES, какбэ, тоже не хэш, и ничего, столько лет использовали в UNIX'овом crypt() (сиречь, passwd) без всяких проблем.
     
     
  • 5.59, sdfsfsf (?), 21:08, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не надо путать "DES-блочный шифр" и "DES-хеш" на основе "DES-блочного шифра".
     
     
  • 6.64, Мимокрок (?), 21:01, 19/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ЕМНИП, из любого блочного шифра можно получить криптографическую хэш-функцию.

    Правда не все будут качественными.

     

  • 1.8, Нанобот (?), 01:09, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > Текущее состояние в области защиты паролей оценивается как неприемлемое - web-сервисы зачастую хранят пароли пользователей в открытом виде

    они наверно думают, что как только разработают новые методы хеширования, все эти веб-сервисы волшебным способом перестанут использовать старые способы хранения паролей и начнут использовать новые

     
     
  • 2.21, solardiz (ok), 05:16, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    См. первый вопрос/ответ в FAQ:
    https://password-hashing.net/faq.html

    А также мой подробный ответ в r/crypto:
    http://www.reddit.com/r/crypto/comments/18j6m8/password_hashing_competition/c

     
  • 2.25, x0r (??), 13:27, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    лечить такое наверно можно только предоставлением функционала из коробки в языке...
    и бейсбольной битой по рукам...
     

  • 1.9, Аноним (-), 01:16, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Откуда такая уверенность, что пароли для веб сервисов хранятся в открытом виде.
     
     
  • 2.10, AnonuS (?), 01:21, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    А уверенность это основана на таком казалось бы пустяшном факте - как не умыкнут базу с паролями, так они все не зашифрованные :-)
     
  • 2.12, angra (ok), 01:27, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Практически во всех местах с регистрацией есть функция восстановления забытого пароля. Где-то при использовании данной возможности генерируют новый пароль, но многие сайты просто присылают старый. Как вы думаете, они его из при помощи сильного колдунства получают или все-таки хранят в открытом виде?
     
     
  • 3.14, Аноним (-), 02:29, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
    > Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
    > просто присылают старый. Как вы думаете, они его из при помощи
    > сильного колдунства получают или все-таки хранят в открытом виде?

    С таким же успехом, можно использовать самый хороший дверной замок, и при этом не закрывать его. Кто-то не использует шифрование паролей, но это же не говорит о том, что это, потому что алгоритм плахой.

     
     
  • 4.29, Аноним (-), 17:31, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    плОхой.
    если замок лежит на полочке, то закрывать его бессмысленно.
     
  • 3.15, Lain_13 (ok), 02:29, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще лично я такое довольно редко видел. Обычно просят указать новый пароль.
     
     
  • 4.17, qqq (??), 02:49, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Первое время на вконтактике высылали старый пароль на почту.
     
     
  • 5.18, Lain_13 (ok), 03:13, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Первое время на вконтактике высылали старый пароль на почту.

    /me фейспальмирует

     
     
  • 6.28, ОоН (?), 16:23, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Контактик помнит скомпрометироанные пароли, такая штука.
     
     
  • 7.30, Аноним (-), 17:33, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Контактик помнит скомпрометироанные пароли, такая штука.

    может он помнит не пароли а хеши?

     
  • 3.32, Аноним (-), 19:14, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Практически во всех местах с регистрацией есть функция восстановления забытого пароля.
    > Где-то при использовании данной возможности генерируют новый пароль, но многие сайты
    > просто присылают старый. Как вы думаете, они его из при помощи
    > сильного колдунства получают или все-таки хранят в открытом виде?

    Ну не совсем в открытом. Это же не файловое хранилище одного известного отечественного сервиса. Хранится, вернее всего, в базе данных MySQL, в зашифрованном виде, причем к базе доступ есть только с localhost. Забраться не так уж легко.

     
     
  • 4.49, Stellarwind (?), 17:09, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну обычно и ломают приложение, а не mysql...
     

  • 1.11, torvn77 (ok), 01:24, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>технических требований к выставляемым на конкурс работам отмечается как минимум поддержка хэширования паролей размером от 0 до 128 символов

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

     
     
  • 2.13, анон (?), 02:07, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    etoken, rutoken  и прочие....
     
     
  • 3.16, Аноним (-), 02:34, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > etoken, rutoken  и прочие....

    Верно, говорите, есть веб сервисы, которые вообще по отпечатку пальца работают, и давно забыли уже о паролях. Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков. Сразу сканер шел от производителя, бук не работал без отпечатка, Этим же сканером можно было пользоваться и в других сервисах.

     
     
  • 4.23, Аноним (-), 11:51, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И как это поможет для web? В чем разница хранить пароль или скан отпечатка пальца?
     
  • 4.57, Michael Shigorin (ok), 19:36, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Пару лет назад на фоне этого даже к нотбукам прилепляли сканеры отпечатков.

    Ах вот оно что, а я-то думал, что это для аутентификации юзера непосредственно на буке (ну или где там сложили образцовые отпечатки при тренировке, помимо полированной мебели).

    Но теперь мы с двумя thinkpad'ами будем знать, что они на самом деле без fprintd не работали.

     
  • 3.46, 4ertus2 (ok), 11:37, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Скачивал я как-то SDK для etoken-ов. Там вместо метровой библиотечки и пары примеров - гигабайта полтора какого-то неструктурированного непортируемого хлама, в котором можно закопаться на месяц. Пол дня посмотрел и плюнул. Не хотят они, чтобы их использовали.
     

  • 1.19, fi (ok), 04:03, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а вот интересно, появится ли алгоритм с челенжом где на сервере не будет храниться пароль  открытым текстом? Например, как это делается в несимметричном ключе.  
     
     
  • 2.20, solardiz (ok), 05:14, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если я правильно понял вопрос, то такие уже есть. RFC 5802 (SCRAM) и еще:
    http://openwall.info/wiki/people/solar/algorithms/challenge-response-authenti
     
  • 2.55, Мимо ракодил (?), 18:43, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот интересно, появится ли алгоритм с челенжом где на сервере не
    > будет храниться пароль  открытым текстом? Например, как это делается в
    > несимметричном ключе.

    Тот же SRP, например: https://en.wikipedia.org/wiki/Secure_remote_password_protocol

     

  • 1.22, exn (??), 11:02, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему такая уверенность что кто-то что-то вообще пришлет ?
     
  • 1.24, Аноним (-), 12:34, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >трудность распараллеливания подбора

    Это вообще как?
    Что мешает пробовать пароли на букву А на одной машине, на Б на другой? Операция подбора параллельна сама по себе.

     
     
  • 2.33, Аноним (-), 19:18, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>трудность распараллеливания подбора
    > Это вообще как?
    > Что мешает пробовать пароли на букву А на одной машине, на Б
    > на другой? Операция подбора параллельна сама по себе

    ну можно тайм-аут сделать минут 15 после неправильного ввода пароля. Неудобство для пользователя, конечно, но, во-первых, это стимулирует использование утилит - связок ключей, а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будет.

     
     
  • 3.34, Аноним (-), 20:20, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  а, во-вторых, пользователь раз посидит минут 15, потом более внимательным будет

    Скорее поменяет пароль на трехбуквенный, в котором не ошибешься

     
     
  • 4.52, Клыкастый (ok), 18:11, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    god, sex, х..
     
  • 3.39, KT315 (ok), 23:12, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ага-ага, застопорит разработку брутфорс-механизма в лучшем случае на 10 минут.
    Система должна быть открытой, а значит легко будет отследить func(delay) и остается стащить хеш или подменить уже модифицированный бинарник c delay = 0;
     
  • 3.45, другой аноним (?), 11:07, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    не путайте специфику работы алгоритма и системы, которая использует этот алгоритм нужным ей образом.

    под подбором в данном случае понимается просто подбор данных под известный злоумышленнику хэш (локально), а не обращение к какой-то удаленной системе, которая проверяет пароли и в случае неправильности блокирует систему. Зачем, имея на руках хэши, перебирать пароли на удаленной системе? Ведь конкурс заявлен просто на алгоритм, а не какой-нибудь сервер а-ля керберос или библиотеки PAM-аутентификации. Аутентификационные сервисы, конечно, могут придумывать разные приемчики типа таймаутов и блокировок, уровни сложности паролей или расписания, когда пользователь может работать в системе, но это не имеет никакого отношения к алгоритмам хэширования (приемчикам манипулирования с массивами байт). Хэширование не имеет никакого отношения к протоколам взаимодействия программных комплексов, это протоколы в своей работе на разных этапах могут использовать алгоритмы хэширования.

     

  • 1.35, Аноним (-), 21:37, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Лучше бы придумали надежного приемника MSCHAPv2, т.е. когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам сервер. За это люди реально скажут *огромное* спасибо и с радостью включат в будущие стандарты.

    http://deployingradius.com/documents/protocols/compatibility.html - Табличка, демонстрирующая проблему на примере радиуса и WPA-Enterprise (хотя можно тоже самое нарисать и для SMTP AUTH, IMAP4, etc, etc):

    В целом впечатления от новости -- обострение NIH-синдрома.

     
     
  • 2.36, XPEH (?), 21:59, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > когда пароль в базе хранится в виде хеша и пароль с клиента для проверки передается в виде другого посоленого хеша, а соль генерирует сам сервер

    Вы из анабиоза восстали что-ли ? Вашим условиям даже древний CRAM-MD5 удовлетворяет.

     
     
  • 3.37, Аноним (-), 22:32, 17/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Бред сивой кобылы.
    CRAM-MD5 -- это тот дырявый алгоритм, который или требует plaintext пароля на сервере, или же промежуточный md5-хеш в базе + специально модифицированный сервер, который пользуется этим промежуточных хешем. В результате, угон или пароля или его хеша позволяет успешно проходить CRAM-MD5 аутентификацию.
    Следующий!
     
     
  • 4.47, XPEH (?), 11:52, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ничего что угон NTLM хеша, используемого в вашем любимом MSCHAPv2, приводит ровно к тому же результату ?

    Не говоря уже о том что NTLM хеш сам по себе ископаемое убожество.

     
  • 2.56, Мимо ракодил (?), 18:47, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы придумали надежного приемника MSCHAPv2

    Да придумано все, и очень давно. EAP-TLS, пароли не нужны.

    Только заставьте теперь дедушку Ляо это в роутеры запихать.

     

  • 1.38, KT315 (ok), 23:09, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Боюсь показаться КЭПом, но конкурс направлен на реализацию системы управления ключами. ИМХО, недавно завершился конкурс хеш-функции на звание SHA-3 и есть достаточно хорошие twofish, aes, serpent блочные шифры.
    Нужен лишь механизм, как эти управлять (правильно организовать генерацию соли, правильный механизм раздутия области хранения инфы, учитывать тип носителя информации и тому подобное) ;-)

    PS: на языке оригинала, как-то все прозрачней и понятней о чем речь, чем перевод.

     
  • 1.40, ILYA INDIGO (ok), 23:49, 17/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >...такие как MD5 или SHA-1...

    Почему все всегда говоря о хэшировании паролей упоминают сразу эти алгоритмы, принимая их за эталонные. и вываливают их недостатки?
    Про sha512 никто не слышал что ли?

     
  • 1.44, Аноним (-), 10:22, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в чем плох метод хранения с солью хэша SHA-2, полученного на основе хэша SHA-2 от пароля ? Словарный перебор как понимаю исключается, а  на полный перебор несколько лет понадобится. Или есть какой-то подвох и современные GPU позволяют свести время такого перебора до дней/месяцев ?
     
     
  • 2.50, Stellarwind (?), 17:18, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Даже md5 с солью вполне достаточно, но 99% просто хранят md5(pass)


     
     
  • 3.61, sdfsfsf (?), 21:41, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, недостаточно.
     
  • 2.60, sdfsfsf (?), 21:37, 18/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С чего это вдруг словарный перебор исключается?! Не исключается он. Это первое.

    Второе. Солёный sha2 - это, конечно, хорошо, Но:
    Конкурс направлен не столько на разработку хеш-функции, сколько на систему, использующую в основе хеш-функцию, и предназначенную для безопасного хранения паролей.

    И эта система должна обеспечивать: применимость к данным довольно большого развмера (до 128 байт), использование соли с большой энтропией, желательно опциональное использование local-parameter (как вторая "соль"), уникального, например для сервера. Очень хотелось бы, что б функция не была сильно эффективна на gpu, fpga etc - для того, что б заведомо не давать атакующему фору (а тот же sha2 двольно быстр на gpu).

    Также требуется возможность тюнинга - настраиваемное "CPU-hardness" (например через число раундов стретчинга, хотя, возможно, есть и другие варианты), "memory-hardness" (если используется). Кроме того, неплохо было бы обеспечить регулирование последних двух для уже посчитанных хешей, не зная при этом паролей.

    Разумеется, нужно придумать удобный формат представления таких хешей, обеспечив портабельность и однозначность ...

    И это далеко не всё, что требуется.

    Исходя из всего этого, мне что-то не кажется, что удачные схемы для целей храниения паролей в данный момент существуют.

    Что-то коммент в сторону ушёл, ну да ладно.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру