The OpenNET Project / Index page

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

Выпуск yescrypt 1.0.0, новой схемы хеширования паролей

16.03.2018 21:51

Вышла первая официальная версия yescrypt, новой схемы хеширования паролей и формирования криптографических ключей на основе паролей или парольных фраз. Yescrypt основывается на scrypt и включает в себя поддержку классического scrypt, консервативной модификации scrypt (под названием YESCRYPT_WORM) и, наконец, глубокой модификации scrypt (под названием YESCRYPT_RW), которая предлагается как основная (и подразумевается под yescrypt далее).

Нравится нам или нет, парольная аутентификация остаётся актуальной, в том числе и при использовании многофакторной аутентификации, а утечка базы данных, содержащей хеши паролей, является одним из рисков. Для снижения последствий такой утечки, используются специализированные методы хеширования, которые на каждую проверку пароля расходуют значительное процессорное время (bcrypt, PBKDF2 и др.), а также оперативную память (scrypt, Argon2 и др.) К сожалению, при сравнительно низком требуемом времени проверки пароля, особенно в сочетании с необходимостью обработки одновременно многих попыток аутентификации, расход оперативной памяти оказывается недопустимо низким, вплоть до того, что scrypt и Argon2 могут оказаться не лучше, чем гораздо более старый bcrypt (с точки зрения атак с использованием существующего оборудования, такого как GPU и узлы ботнета).

Наиболее важной для крупных внедрений является возможность yescrypt инициализировать и использовать большую таблицу данных, обычно занимающую десятки или сотни гигабайт оперативной памяти и фактически представляющую собой специфичную для конкретного внедрения постоянную память (ROM), что ограничивает использование существующего оборудования для атаки. Другие отличия yescrypt от scrypt и Argon2 еще более снижают эффективность атак, использующих GPU, FPGA и специализированные микросхемы даже если использование памяти низкое (и даже при отсутствии ROM). Yescrypt также предоставляет дополнительные настройки и встроенные возможности (в частности, шифрование хешей).

С одной стороны, yescrypt - наиболее масштабируемая схема хеширования паролей, так как он предоставляет почти оптимальный уровень безопасности от offline-атак для широкого диапазона используемого объема памяти, от килобайт до терабайт и выше. С другой стороны, цена этого - в сложности yescrypt, а сложность является недостатком любого ПО. По этой причине, на данный момент yescrypt предназначается для крупных внедрений (миллионы паролей), где сложность yescrypt мала по сравнению с общей сложностью сервиса аутентификации. Для меньших внедрений и интеграции в программы, пока что bcrypt остается разумным краткосрочным выбором, хотя наблюдается прогресс в атаках на bcrypt с использованием FPGA. Возможно, позже будет выпущена упрощенная версия yescrypt и/или появится его поддержка в популярных библиотеках, что упростит правильное использование yescrypt для меньших внедрений и в программах.

Разработка yescrypt фактически началась в 2012 году с введения концепции ROM-port-hardness, представленной на конференции ZeroNights 2012 и продолжилась во взаимодействии с различными людьми, проектами и компаниями. В частности, предыдущие редакции yescrypt подавались на Password Hashing Competition (PHC) в 2014-2015 годах, где в качестве победителя был выбран Argon2, а yescrypt получил "специальное признание" за "богатую функциональность и простоту обновления с scrypt", проиграв Argon2 в первую очередь из-за своей сложности.

Выпущенный сейчас yescrypt 1.0.0 совместим с последней поданной в рамках PHC редакцией в отношении обязательной для PHC функциональности, но отличается в дополнениях. Подробно о проблеме хеширования паролей, решаемой yescrypt, и о его дизайне и свойствах, можно узнать из доклада (слайды, видео) с конференции BSidesLjubljana 2017. Некоторые подробности на нескольких слайдах в конце этой презентации относятся к yescrypt 0.9.x и устарели для 1.0+ (алгоритм инициализации ROM стал проще и быстрее), но в целом эта презентация по-прежнему актуальна. Версии yescrypt 0.9.x уже внедрены (с участием разработчиков) в некоторых известных Интернет-компаниях для защиты миллионов паролей, а yescrypt 1.0+ будет использоваться для дальнейших внедрений.

Yescrypt обеспечивает высокую производительность на современных системах и хорошую на предыдущих поколениях оборудования. В качестве примера, на современном сервере (предоставленном компанией Packet) с двумя процессорами Xeon Gold 5120 (2.2 GHz, turbo вплоть до 3.2 GHz) и 384 GiB RAM (12x DDR4-2400 ECC Reg), что обеспечивает 28 физических ядер (56 логических) и 12 каналов памяти, инициализация 368 GiB ROM занимает 22 секунды (обычно будет производиться сразу после загрузки системы). При использовании этого ROM, yescrypt вычисляет более 21 тыс., более 10 тыс. или около 1200 хешей в секунду при использовании объемов RAM, соответственно, 1.4375 MiB, 2.875 MiB или 23 MiB на вычисление каждого хеша. Без использования ROM, примерно те же скорости достигаются при, соответственно, 2 MiB, 4 MiB или 32 MiB RAM на вычисление каждого хеша.

Уже существуют криптовалюты (по подсчетам разработчиков одной из них, таких недавно было восемь), ориентированные на майнинг на CPU и использующие yescrypt версии около 0.5 (модификация первой редакции, предложенной на PHС в 2014) в качестве схемы proof-of-work (PoW). Это дало yescrypt хорошую проверку "в бою" (в том числе появились реализации на GPU, дающие ожидаемо низкую производительность). Несмотря на это, разработчики пока что не рекомендуют yescrypt 1.0+ для применения в криптовалютах, а вместо этого советуют желающим создать или клонировать одну из криптовалют на основе yescrypt продолжить использование той же старой редакции yescrypt, которую уже используют другие. Возможно, позже будет предложен специальный режим yescrypt, ориентированный на применение в качестве PoW.

  1. Главная ссылка к новости (http://www.openwall.com/lists/...)
  2. OpenNews: Представлена хеш-функция BLAKE2, претендующая на роль высокопроизводительной замены MD5 и SHA1
  3. OpenNews: Проект Openwall подготовил модуль для защиты от эксплуатации уязвимостей в ядре Linux
  4. OpenNews: Автор md5crypt подчеркнул небезопасность данного алгоритма и призвал перейти на более стойкие методы хэширования паролей
  5. OpenNews: Оценка эффективности хэширования паролей на крупном GPU-кластере
  6. OpenNews: Инициатива по разработке новых методов хэширования паролей
Автор новости: solardiz
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48275-yescrypt
Ключевые слова: yescrypt, scrypt, password, hash
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:44, 16/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Ну нормальные такие современные системы.  Жалко что с текущим курсом доллара я их увижу ещё не скоро
     
     
  • 2.7, solardiz (ok), 00:01, 17/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тестовая система соответствует тому, что скоро будет у клиентов на подобные "крупные" внедрения, хотя на данный момент это типично кластер из N-го количества серверов с 2x Xeon E5-26xx v3 или v4, от 8 до 14 ядер на чип. yescrypt отлично работает и на мелких системах, но для нашей изначальной целевой аудитории брать сервера меньше не рационально (их потребуется соответственно больше).
     

  • 1.3, Аноним (-), 23:36, 16/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >расход оперативной памяти оказывается недопустимо низким, вплоть до того, что scrypt и Argon2 могут оказаться не лучше, чем гораздо более старый bcrypt

    Вообще-то аргон параметризуется как по памяти, так и по вычислениям.

     
     
  • 2.5, solardiz (ok), 23:42, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Конечно, но увеличивая m_cost мы косвенно увеличиваем и объем вычислений (а через него, время). Эти параметры не являются полностью независимыми (не могут быть, кроме как для yescrypt ROM или подобного) ни в одной схеме. Поэтому расход памяти на хеш оказывается ограничен требованиями по количеству обрабатываемых запросов в секунду и максимальной задержке.
     

  • 1.4, Аноним (-), 23:40, 16/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    solardiz, а почему у вас сайт без TLS?
     
     
  • 2.6, solardiz (ok), 23:45, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > solardiz, а почему у вас сайт без TLS?

    Legacy, нежелание увеличивать attack surface, нежелание впоследствии получать ссылки/запросы по https и тем самым создавать на ровном месте лишние сложности в случае (D)DoS. Но, конечно, скоро это придется менять, что и хорошо и не очень.

     
  • 2.14, Аноним (-), 18:28, 17/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Даже у этих ребят не настроен https
    http://www.academy.fsb.ru/index_i.html
    хотя бы ради приличия поставили
     
     
  • 3.18, Аноним (-), 12:04, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это не про них случайно полицейскую академию сняли? Они наверное везде одинаковые.
     
     
  • 4.23, Michael Shigorin (ok), 23:35, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это анонимы, спрашивающие эксперта по безопасности и ставящие ему минусы за внятный и вразумительный ответ -- везде одинаковые.  А люди, благодаря которым даже такие анонимы могут жить, ковыряя пальцем в носу -- они каждый особенный.
     
     
  • 5.25, Аноним (-), 00:54, 19/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Это анонимы, спрашивающие эксперта по безопасности и ставящие ему минусы за внятный
    > и вразумительный ответ -- везде одинаковые.  А люди, благодаря которым
    > даже такие анонимы могут жить, ковыряя пальцем в носу -- они каждый особенный.

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

    //но сабжевый алгоритм все-таки малость не от мира сего, на грани экстремизма от безопасников.

     

  • 1.15, Аноним (-), 19:37, 17/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждем оптимизации для hashcat
     
  • 1.16, Аноним (-), 19:39, 17/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    LUKS v1 уже умеет брутфорсить на гибриды hashcat
     
  • 1.17, Аноним (-), 12:01, 18/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > поддержку классического scrypt, консервативной модификации scrypt
    > (под названием YESCRYPT_WORM)
    > и, наконец, глубокой модификации scrypt

    FAIL сразу на старте. Алгоритм должен быть 1, зато хороший. А выбирать из 3 разных - аффтыри уверены что все вокруг эксперты в криптографии с должной квалификацией, чтобы осмысленно выбирать? Оптимизм это хорошо, конечно, но...

     
     
  • 2.20, solardiz (ok), 14:55, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это обсуждалось в PHC - нужен один или несколько победителей и/или вариантов алгоритма (для разных применений?) Многие были за один умеренно хороший, но зато универсальный вариант. Выбрали один алгоритм как победитель - Argon2 - хотя и у него уже на тот момент было два варианта (2d и 2i) и еще некоторые обсуждались (2ds, 2id - причем сейчас 2id рекомендуется авторами как основной). В некотором смысле это fail, но не всё так просто. С позиции исключительно такой, что алгоритм нужен один, PHC был не нужен. Можно было бы сказать что у нас уже есть хороший scrypt, а лучшее - враг хорошего. Но с другой стороны scrypt уже был далеко не единственным, это направление развивается с 1970-х годов, в нем есть недавние существенные достижения (особенно scrypt в 2009) и PHC дал существенные новые результаты (до PHC никто всерьез не занимался созданием и атаками на time-memory trade-off resistant схемы). Даже у одного алгоритма есть параметры, выбор которых не менее важен, чем выбор самого алгоритма. Отказ и от параметров вернул бы нас в 1980-е, то есть такой вариант по современным меркам не был бы даже хорошим.

    Что касается трех поддерживаемых в yescrypt алгоритмов: scrypt уже существовал и уже широко используется (так что мы не делаем хуже поддерживая с ним совместимость в том же дереве исходников), YESCRYPT_RW нами рекомендуется для внедрений именно yescrypt (и только в этом варианте поддерживается ROM), а YESCRYPT_WORM предназначен для авторов сторонних реализаций scrypt для тех их пользователей, кому нужно управлять временем работы отдельно от расхода памяти и параллелизма (в scrypt отдельного параметра для этого не было), при этом не заставляя их ради этой мелочи реализовывать весь yescrypt. Я согласен, что нам следует явно и на видном месте указать предназначение этих вариантов, а также рекомендуемые сейчас параметры.

     

  • 1.19, Аноним (-), 12:12, 18/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > специализированные микросхемы даже если использование памяти низкое (и даже при отсутствии ROM)

    А в чем пойнт ROM? Большой объем RAM делать в ASIC как бы затратно, конкурировать с производителями DRAM смысла мало. Но ROM делать еще проще и конкурентов нет...

     
     
  • 2.21, solardiz (ok), 15:11, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ROM обеспечивает меньший чем RAM уровень защиты в расчете на байт (так как ROM можно использовать для большого количества вычислений одновременно), но зато его объем не ограничен требованиями по количеству вычисляемых хешей в секунду и времени ответа (объем RAM ими ограничен так как RAM надо успеть заполнить и хотя бы частично прочитать обратно с помощью выделенной доли вычислительных ресурсов и за выделенное время, а иначе атакующий сможет применить меньший объем).
     
     
  • 3.22, Аноним (-), 19:21, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    я ничего не понял.
     
     
  • 4.24, Аноним (-), 23:44, 18/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    обработка и хранение специфической информации в RAM/ROM с учётом возможных атак на них и процесс (тайминг, фирмваре, дос, тд)

     
  • 4.27, Аноним (-), 02:07, 19/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > я ничего не понял.

    Он грузновато объяснил, суть сводится к тому что ROM может быть более крупным без ущерба для производительсности алгоритма.

    Насколько это хорошо - черт его знает. Алгоритм становится memory hog, как я понимаю интенсивнее чем RAM-based. А насколько кто на этой планете готов целиком выкроить 100500 ядерный ксеон и сотни гигз только для проверки паролей - интересный вопрос. Даже толстые энтерпрайзы будут давиться жабой. Но как один из вариантов на выбор - почему бы и нет? Вдруг кому такое все же понравится.

     

  • 1.28, Аноним (-), 11:04, 19/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я чет недопонел.... продвинутость безопасности решения сводится к наличию ROM и предполагается, что у атакующего его не будет, поэтому ему нужно будет гораздо более мощное оборудование? Или смысл таки в чем-то другом?
     
     
  • 2.31, solardiz (ok), 15:53, 19/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не "сводится" к наличию ROM - в yescrypt есть еще несколько важных отличий, которые "снижают эффективность атак [...] даже если использование памяти низкое (и даже при отсутствии ROM)". Они перечислены в "Comparison to Argon2" на странице yescrypt и подробно описаны в докладе с BSidesLjubljana 2017 и в PDF'е на сайте PHC. Да, ROM защищает от части возможных атак, где иначе было бы эффективно применено уже имеющееся в большом количестве и без дополнительных затрат оборудование, такое как узлы ботнета и/или GPU. (От нынешних GPU в yescrypt есть и другой способ защиты, не требующий больших объемов памяти, но GPU развиваются.)
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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