The OpenNET Project / Index page

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

Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA

17.05.2019 20:53

Выпущена новая версия старейшей поддерживаемой программы для подбора паролей John the Ripper 1.9.0-jumbo-1 (проект развивается с 1996 года). C выхода прошлой версии 1.8.0-jumbo-1 прошло 4.5 года, за которые было внесено более 6000 изменений (git commits) от более 80 разработчиков. Благодаря непрерывной интеграции, включающей предварительную проверку каждого изменения (pull request) на многих платформах, в течение этого срока разработчики рекомендовали использовать текущую редакцию с GitHub, состояние которой поддерживалось стабильным несмотря на вносимые изменения. Код большинства компонентов доступен под лицензией 0-clause BSD, но при этом на весь проект в целом распространяется лицензия GPLv2+.

Особенностью новой версии является появление поддержки FPGA (в дополнение к CPU, GPU и Xeon Phi). Для плат ZTEX 1.15y, включающих по 4 чипа FPGA и исходно использовавшихся в основном для майнинга Bitcoin, теперь реализованы 7 типов хешей паролей: bcrypt, классический descrypt (включая bigcrypt), sha512crypt, sha256crypt, md5crypt (включая Apache apr1 и AIX smd5), Drupal7 и phpass (используется, в частности, в WordPress). Некоторые из них реализованы на FPGA впервые.

Для bcrypt, достигнутая производительность в ~119k c/s при 2^5 итераций ("$2b$05") с потребляемой мощностью около ~27 ватт существенно превосходит результаты для новейших GPU в расчете на плату, на цену оборудования и на ватт. Также поддерживаются кластеры из плат этого типа, что проверено вплоть до 16 плат (64 чипа FPGA), контролируемых с одного Raspberry Pi 2. Поддерживается обычная функциональность John the Ripper, включая все режимы подбора паролей и одновременную загрузку большого количества хешей.

Для ускорения работы реализовано применение маски (режим "--mask", в том числе в комбинации с другими режимами) и сравнение вычисленных хешей с загруженными на стороне FPGA. С точки зрения реализации, во многих из дизайнов (например, для sha512crypt и Drupal7) применены блоки состоящие из многопоточных процессорных ядер (soft CPU cores), взаимодействующих с криптографическими ядрами. Разработку этой функциональности вел Денис Бурыкин в координации с другими разработчиками jumbo.

Другие важные изменения:

  • Поддержка большого количества дополнительных типов хешей, шифров и т.п., включая как классические хеши паролей (например, от новых версий QNX), так и кошельки криптовалют, шифрованные архивы и шифрованные файловые системы (например, Bitlocker и FreeBSD geli), а также поддержку новых разновидностей форматов, поддерживаемых ранее (например, добавлена поддержка bcrypt-pbkdf для OpenBSD softraid) и многое другое. В общей сложности, добавлено 80 форматов на CPU и 47 на OpenCL. Общее количество форматов теперь 407 на CPU (или 262 не включая "dynamic" форматы, настраиваемые из файлов конфигурации) и 88 на OpenCL.
  • Отказ от поддержки языка CUDA в пользу OpenCL, что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее).
  • Поддержка новых наборов инструкций SIMD - AVX2, AVX-512 (в том числе для второго поколения Xeon Phi) и MIC (для первого поколения) - а также более универсальное и полное использование SIMD в реализациях многих форматов, включая применение ранее поддерживаемых наборов инструкций вплоть до AVX и XOP на x86(-64) и NEON, ASIMD и AltiVec на ARM, Aarch64 и POWER, соответственно.
  • Многочисленные оптимизации для CPU и OpenCL, как для более эффективной работы с большим количеством хешей одновременно (например, проверялась загрузка 320 миллионов хешей SHA-1 на GPU), так и для повышения скорости вычисления хешей. Часть из этих оптимизаций универсальные, часть охватывает различные подмножества форматов, а многие специфичны для отдельных форматов.
  • (Авто-)настройка оптимальной буферизации проверяемых паролей на CPU ("--tune=auto --verbosity=5") и оптимальных размерностей задания на OpenCL (включена по умолчанию), в том числе с учетом медленного выхода на полную рабочую частоту GPU серии NVIDIA GTX 10xx и новее. Использование реально загруженных хешей и реальной длины проверяемых паролей (когда она известна заранее) для такой авто-настройки.
  • Добавление компилятора "динамических выражений", указываемых прямо на командной строке и реализующих новые гибридные типы хешей, например "--format=dynamic='sha1(md5($p).$s)'", вычисляемые на CPU с использованием SIMD. В качестве компонентов таких выражений поддерживаются десятки быстрых хешей (от распространенных вроде MD5 до умеренно экзотических вроде Whirlpool), объединение подстрок, кодирование и декодирование, преобразование регистра символов, ссылки на пароль, соль, имя пользователя и строковые константы.
  • Устранение нежелательных отличий от hashcat, в том числе поддержка ранее специфичных для hashcat правил (wordlist rule commands), переход на нумерацию OpenCL устройств с 1-го, применение по умолчанию тех же длин паролей (обычно длина 7) при тестах производительности.
  • Новые режимы генерирования проверяемых паролей (cracking modes), включая PRINCE из hashcat (формирует "фразы", объединяя несколько слов в порядке возрастания суммарной длины), subsets (подбирает пароли с недостаточным количеством различных символов, даже если эти символы пришли из большого набора возможных) и hybrid external (позволяет внешним режимам, описываемым в файлах конфигурации на Си-подобном языке, формировать много проверяемых паролей на основе каждого базового "слова", поступившего от другого режима). Также добавлено несколько новых предопределенных внешних режимов.
  • Дополнительные возможности по использованию нескольких режимов одновременно (один поверх другого - stacking), а также по такому использованию наборов правил (wordlist rules stacking).
  • Усовершенствования режимов mask (постепенное растягивание маски в указанном диапазоне длин, применение маски на стороне OpenCL-устройства или платы FPGA) и single crack (разумное поведение на устройствах, вычисляющих большое количество хешей параллельно, на что ранее в этом режиме не хватало проверяемых паролей, а также ограничения на расход памяти).
  • Много улучшений, связанных с поддержкой Unicode и других кодировок в разных подсистемах.
  • Много улучшений программ *2john (преобразующих файлы разных форматов для использования с john), в особенности wpapcap2john (обрабатывает WiFi трафик).
  • Много новых опций командной строки, настроек в john.conf, опций configure-скрипта и соответствующие им новые возможности, далеко не все из которых удалось упомянуть здесь.
  • Повышение качества кода благодаря встроенной поддержке отладочных сборок с AddressSanitizer (была ранее) и UndefinedBehaviorSanitizer (добавлена), добавлению встроенного фаззера форматов (в рамках GSoC 2015), применению непрерывной интеграции (сборки под десятки сочетаний операционной системы и компилятора и тестирование в них корректной поддержки всех форматов).


  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Вышел John the Ripper с поддержкой GPU (CUDA и OpenCL)
  3. OpenNews: В рамках проекта John the Ripper найдены упрощенные выражения для S-box'ов DES
  4. OpenNews: Вышел John the Ripper 1.7.6 с поддержкой параллелизации
  5. OpenNews: Выпуск yescrypt 1.0.0, новой схемы хеширования паролей
  6. OpenNews: Выпуск модуля LKRG 0.6 для защиты от эксплуатации уязвимостей в ядре Linux
Автор новости: solardiz
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50702-johntheripper
Ключевые слова: johntheripper, password
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, DHCPep (?), 22:39, 17/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Скажите кто может оценить. Для приведённого формата хеша sha1(md5($p).$s) какой должен быть длины пароль (минимум), чтобы перебор его был невозможен например для условного гугла за год.

    Соль тут я так понимаю принципиального значения не имеет. Она же лишь для исключения словаря.

    А также насколько адекватно хранение хеша пароля например такого
    md5(md5($p).$s)

    Тут же коллизию пароля хер подберёшь, ведь там ещё и соль?

     
     
  • 2.2, solardiz (ok), 23:02, 17/05/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Подобные хеши (кое-как составленные из небольшого количества вычислений быстрых хешей, также не предназначенных для паролей) - болезнь веб-приложений 2000-х, которая постепенно начала проходить в 2010-х. Ни одним из подобных способов хешировать пароли не следует. Для паролей следует использовать специально предназначенные хеши, такие как bcrypt, scrypt, yescrypt или Argon2. В веб-приложениях на PHP 5.5+, следует использовать интерфейс password_hash(): https://www.php.net/manual/en/function.password-hash.php

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

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

    Вопрос про коллизии тем более не актуален по ряду причин.

     
     
  • 3.5, вот такая вот куйня (?), 02:00, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты ни черта не прав, кроме разве что быстрой криптографической функции Те же KD... большой текст свёрнут, показать
     
     
  • 4.7, solardiz (ok), 02:53, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Про KDF ты в целом понимаешь правильно, а в моем комментарии упустил слова "из небольшого количества вычислений".

    Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся.

    Про "меркнет по скорости" перед rainbow tables не так просто - тут влияет много факторов. А соль начали использовать до появления rainbow tables (1970-е vs. 1990-е), так что предназначена она была не непосредственно против них, да и сейчас несет несколько функций.

     
     
  • 5.18, хотел спросить (?), 11:54, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся.

    поиск коллизий основа взлома хешей

     
     
  • 6.19, пгуыыцрщ (?), 12:29, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    [offtopic] Даешь спор с автором риппера! [/offtopic]
     
     
  • 7.22, Sw00p aka Jerom (?), 15:59, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    таки да, поиск коллизий
     
  • 4.27, анон (?), 22:21, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Конкретно по MD5, это 128-bit, что в теории больше времени жизни вселенной

    да хоть 512 или 1024 бит, причем здесь биты если сам алгоритм дырявый? коллизия к твоим 128 битам на обычных процах у МД5 находиться за время.... сюрпрайз МИНУТЫ!!!

     
     
  • 5.29, хотел спросить (?), 02:43, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чукча - не читатель, чукча - писатель?

    ты может для начала пост прочтешь целиком?

     
  • 3.30, Зябор (?), 14:01, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А скажите пожалуйста. Вот я так понимаю проблема хранения хеша пароля в виде bcrypt предпочтительней в первую очередь из-за скорости вычисления, что приводит например в случае утекания базы хешей, к неподъёмному времени взлома.

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

    А скажите насколько допустим такой например двух-этапный способ, когда например в БД хранить вариант bcrypt'а, а вместе с тем ещё хеш например substr(md5($u.$s.$p)), 0, 8) и сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом?

    Или это просто дикий костыль?

     
     
  • 4.31, solardiz (ok), 15:38, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "bcrypt предпочтительней в первую очередь из-за скорости вычисления" - да. "к неподъёмному времени взлома" - это зависит еще и от выбора паролей.

    "Тут или городить капчи, или бороться с кол-вом коннектов в единицу времени." - да, но еще нужно учесть что у сервиса и до внедрения "тяжелого" хеширования паролей почти наверняка были другие аналогичные с точки зрения риска DoS слабые места, так что чтобы не сделать сервер более уязвимым к DoS достаточно настроить хеш так, чтобы он не был медленнее обработки другого самого медленного запроса, также доступного до аутентификации. Например, переход с быстрого не-парольного хеша вроде MD5, занимавшего 1 микросекунду, на bcrypt, настроенный на время 10 ms, на типичном веб-сервисе не повысит уязвимость к DoS (зачастую найдутся и другие запросы, занимающие 10+ ms или требующие больше I/O), но замедлит подбор паролей по украденным хешам на порядки. А с DoS можно бороться отдельно, для всех типов запросов.

    "сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.

     
     
  • 5.33, Зябор (?), 16:59, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за пояснения.
     
  • 5.34, Зябор (?), 18:56, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё один возможно глупый вопрос, по этой же теме. А вариант всё-таки хранения в БД "быстрого" хеша вдобавок к "правильному". Но этот "быстрый" если допустим формируется "чёрным ящиком"?

    Я тут понимаю, что в случае "чёрного ящика" - при компроментации сервера и этот чёрный ящик становится тоже доступен атакующему. Но если пойти дальше и "чёрный ящик" сделать действительно таковым, т.е. отдельно от серверов на которых крутится сервис иметь выделенный сервер на который при регистрации/смене пароля отправляются данные для формирования этого "быстрого" хеша непонятного способа формирования, и при авторизации отправляются данные для проверки его же. И уже в случае положительного ответа - проверяется "правильный" хеш.

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

    Велосипед?

     
     
  • 6.35, solardiz (ok), 21:46, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Таких случаев, чтобы не было ресурсов на хоть насколько-то медленный хеш, вычисляемый всегда, не бывает. Всегда можно, например, заменить микросекунду на миллисекунду без заметного ущерба для производительности всего сервиса. Поэтому хранить не-парольный быстрый хеш совершенно ни к чему.

    Если есть ресурсы на внедрение черного ящика (и не одного - для отказоустойчивости), то тем более они есть и на медленный хеш. Эти вещи хорошо использовать вместе - см. слайды от https://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/mgp00 и далее (а можно и предыдущие тоже) и реализацию https://github.com/SUNET/VCCS. Там используется HMAC на HSM поверх вычисляемого на обычном сервере медленного хеша, хотя есть определенные преимущества (а в некоторых случаях и недостатки) использования вместо этого обратимого шифрования "черным ящиком" медленных хешей, вычисленных на обычном сервере. Мы (Openwall) консультируем по таким внедрениям, так что если интересует всерьез - обращайтесь.

    Хранить и проверять еще и какой-то более "правильный" хеш, не требующий "черного ящика", при этом не следует. Это лишь снижает пользу от применения "черного ящика". Насчет "поставил свой всегда дающий "истину" на запросы авторизации" - "черный ящик" не должен отвечать да/нет (он и не может - у него нет доступа к БД), а лишь довычислять или шифровать хеши.

     
     
  • 7.37, Зябор (?), 07:43, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо!
     
  • 5.39, PnDx (ok), 11:58, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > "сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.

      Утверждение неверно. И вот почему:
    При *совместной* проверке обоих хэшей необходимо предоставлять вектор (строку), для которого обе проверки валидны. Т.о., атакующий должен вместо подбора первой попавшейся коллизии найти пересечение на множествах коллизий обеих функций. Которое в "плохом" сценарии вообще может оказаться единственным. Но даже в "хорошем" случае решение задачи никогда не будет легче подбора коллизии на самый "сильный" хэш из пары.

     
     
  • 6.40, solardiz (ok), 13:42, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Предполагается, что основной хеш (в данном контексте - bcrypt) достаточно устойчив к коллизиям, чтобы это не было проблемой. Вообще, коллизии в криптографических хешах - в частности, даже те что известны для MD5 и SHA-1 - обычно не являются проблемой при использовании этих хешей для паролей. (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и пропуск вычисления медленного) - очень серьезная проблема.
     
     
  • 7.41, PnDx (ok), 13:47, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении
    > реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте
    > выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и
    > пропуск вычисления медленного) - очень серьезная проблема.

      Да, в случае когда за приемлемое время решается задача "подобрать все коллизии вот на эту функцию". MD5? Да, Вы правы.

     
     
  • 8.42, solardiz (ok), 14:11, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Задача подобрать коллизии вот на эту функцию при подборе паролей обычно не ста... текст свёрнут, показать
     
  • 2.26, анон (?), 22:19, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    МД5? серьезно? да хоть обзаворачивайся в 100500 уровней.
     

  • 1.3, Алиса (??), 23:56, 17/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Достаточно ли моей рабочей машины из двух Xeon E5-2690v4 и GTX 1080 Ti для подбора ключа к IP-core от Intel. Там, как понимаю, используется толи AES-128 то ли ещё какая-то подобная штука. Не очень понимаю в этих технологиях, просто хочу попробовать расшифровать исходный код, который закодирован вроде как AES-128.
     
     
  • 2.6, вот такая вот куйня (?), 02:13, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    достоверных дырок в AES-128 никто пока не находил
    лучшее что удалось это снизить сложность до 2^126
    а значит если нет возможности по сторонним каналам, а только прямым перебором
    то тебе понадобится ~10^38 операций, что означает что если ты сможешь делать 1 триллион операций в секунду, то тебе все еще понадобится 10^26 секунд или

    3,170,979,198,376,458,650 лет

    так что про мамкиного хакера было прикольно )))

     
  • 2.8, solardiz (ok), 03:46, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Эта тема почти не имеет отношения к JtR и новости, но всё же отвечу:

    Зависит от того, как Intel формирует ключ. Если хорошо, то (как уже ответили другие) шансов именно подобрать ключ нет. А если плохо, то надо знать или угадать как именно (например, каким инструментом разработки, а потом изучать как тот формирует ключи). Возможно, расшифровка всё равно осуществляется где-то во время синтеза, и ключ можно перехватить на своем же компьютере, ничего не подбирая? Но даст ли расшифровка исходники или, может быть, netlist? Вопросы скорее риторические, чтобы указать ими куда копать, если правда интересно.

    Некоторые конкретности по теме есть тут:

    https://www.cise.ufl.edu/~teshrim/ieee-final.pdf
    https://eprint.iacr.org/2017/828 "The paper was withdrawn for non-scientific reasons, and the results in this paper are correct." но статья всё равно доступна по ссылке выше
    https://www.kb.cert.org/vuls/id/739007/
    https://www.intel.com/content/www/us/en/programmable/documentation/mwh14099606

    Мне непонятно, какой моделью угроз руководствовались авторы статьи и CERT. Если верно моё понимание, что ключ всё равно в какой-то момент оказывается в памяти компьютера, на котором работает EDA (см. "Figure 3: Work flow of the P1735 standard." в статье), то его оттуда можно просто извлечь. Авторы и CERT "не слышали" про reverse-engineering и анализ памяти приложения или же считают, что атакующие почему-то ограничатся какими-то "более этичными" или не нарушающими какие-то юридические условия способами? Странно. Но тем не менее, статья, похоже, о том как даже не прибегая к тому чтобы посто подсмотреть ключ, всё равно можно расшифровать через oracles.

     
     
  • 3.11, Nightfall (?), 08:33, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Привет, Солар. Немного не по теме, но не расскажешь какие ОС используешь дома (для персонального, частного пользования) и почему? Ты раньше был втянут, скажем так, во взаимодействие с андеграундом, у тебя брали вью во фраке и тп. , давным давно ты даже принимал участие во всяких хакерских е-зайнах, я помню твои эксплоиты кое-где. Поддержваешь ли ты какие-нибудь связи и как оцениваешь состояние так называемой "сцены"? Как ты относишься к вирусным технологиям в мире unix/linux (эта тема малопопулярна и мало исследованна, но что называется in the wild сейчас водятся несколько достаточно интересных экземпляров)?
     
     
  • 4.24, solardiz (ok), 18:32, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сильно не по теме, да и я не планировал давать интервью. Это нарушение OPSEC, но думаю уже не секрет что я использую QubesOS - делал с нее доклады, показывал USB passthrough как раз для доступа к ZTEX FPGA плате из VM'ки. На серверах всё еще наша Owl с дополнениями. Пока в целом полет нормальный, но устраивает не всё, да и системы устаревают. Не исключаю уход с Linux. Мой Phrack prophile еще достаточно свежий, от 2016 года - там я отвечаю на схожие вопросы про "сцену", так что если интересно, перечитай его. Не помню, чтобы я публиковал exploit'ы в e-zine'ах. Немного публиковал их в Bugtraq. Вирусы под Unix пока in the wild не встречал - видимо, у нас и наших клиентов не настолько стандартные настройки систем. Думаю, именно разнообразие систем и настроек сдерживает распространение вирусов под Unix-подобные системы.
     
     
  • 5.25, Ан.Зонд (?), 22:03, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нужно было использовать macOS как и все в Кремниевой долине.
     

  • 1.10, Аноним (10), 07:48, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее).

    Максим, эта формулировка звучит по-детски, убого и непрофессионально и, пока не провели тесты, говорить о том, что the OpenCL implementation might be as fast as, or faster then the CUDA implementation on NVIDIA GPUs, рано.

    // b.

     
     
  • 2.21, solardiz (ok), 15:46, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мы (разработчики) проводили тесты и мы говорим конкретно о нашей реализации в JtR. Мы не утверждаем, что CUDA чем-то еще кроме переносимости хуже OpenCL'я - это не так, в CUDA есть возможности, которых в OpenCL нет (но которые нам пока не понадобились). Мы лишь утверждаем, что сфокусировавшись на OpenCL'е мы получили результат лучше, чем получался когда мы делили наше время на разработку под CUDA и OpenCL одновременно. Кстати, такое же решение принял проект hashcat. Еще одним аргументом в пользу OpenCL (и одной из причин почему hashcat стал Open Source) является хорошо укладывающаяся в концепцию OpenCL адаптация сборки под конкретную задачу - изменение "исходного" кода для конкретных загруженных хешей в нашем случае (что делается, в особенности для descrypt). На CUDA так тоже можно делать - так делает ProgPoW - но исторически CUDA используют не так. OpenCL не мешает нам (во всяком случае, не в большей степени, чем CUDA) использовать оптимизации, специфичные для конкретных архитектур GPU (у нас там даже есть чуть-чуть inline PTX asm, то есть под NVIDIA).
     

  • 1.12, Aytishnik.com (ok), 09:52, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Очень хорошая прога, выручает часто, так как иногда забываю пароли, фирм обслуживаю много, поди вспомни какой пароль пять лет назад ставил.
    Вот и выручает каждый месяц. Спасибо разработчикам.
     
     
  • 2.14, Аноним (14), 11:18, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И не говори: поди вспомни, где поставил 12345, где 54321, а где и вовсе qweasdzxc…
     
     
  • 3.16, пох (?), 11:44, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    блин. да у тебя вообще феноменальная память. Я такие сложные (кроме, понятно, первого, его уже выучил, кстати, как ты узнал мой пароль от всех корпоративных систем?) на бумажке к монитору клею.

     
  • 2.15, Аноним (10), 11:41, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вас, батенька, уволить надо за такую безопасность. Пароли, которые подбираются за вменяемое время - это не пароли, а шутка юмора.

    // b.

     
     
  • 3.17, пох (?), 11:48, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    во-первых, тебя или твоего коллегу его клиенты уже уволили - и наняли дешевого аутсорсера, как видишь. Ты ненужен, смирись. Попробуй свои силы в сдаче аллюминиевых баночек.

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

     
     
  • 4.51, InuYasha (?), 12:26, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    попридржи дубину-то )
    Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.
     
     
  • 5.53, пох (?), 13:00, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.

    ты будешь смеяться, но даже если не сам-  то издевается над такими.
    То есть это реальная и регулярная проблема обслуживающих микролавочки с полутора инвалидами - то сами в виду бардака "кто это настраивал три года назад? Вася? Вася под каток попал еще год тому, все пароли пропали!" то между их визитами кто-то еще успел "поработать".

    Ну а поскольку пароли обычно не идут дальше "win123456" - то подобрать их удается за вполне конечное время (самый херовый - фио и мабила "настройщика обоев". Поскольку как его звали никто не помнит, да и номера тоже, а пароль длинный).

    Причем тут "по сети"? Локально он их подбирает, скопировав юзербазку любимым линуксом.
    На fpga, понятен, у таких денег не наберется, да им и не надо. В конце-концов, ненадолго выключат майнилку - и подберут на своей нвидии.

     

  • 1.20, OpenEcho (?), 14:52, 18/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Потребление 27 ватт... офигеть, мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется
     
     
  • 2.23, solardiz (ok), 16:03, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Во-первых, эти подходы имеют этические и юридические отличия.


    Во-вторых, это другая модель угроз, к bcrypt (о котором были 27 ватт) обычно не относящаяся - для bcrypt обычно атакуют большое количество хешей одновременно (многих пользователей), часто с целью выявления слабых паролей, исследовательской и т.п.

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

     
     
  • 3.43, OpenEcho (?), 23:50, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Во-первых, эти подходы имеют этические и юридические отличия.

    solardiz, дорогой, у Вас очень плохое чувство юмора...

     
  • 3.54, Аноним (54), 13:27, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Особенно обидно, когда третье происходит непосредственно во время перебора. Как говорится, "Вскрытие показало, что больной умер от вскрытия"
     
  • 2.28, анон (?), 22:30, 18/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну подбери своим паяльником пароль к кошельку где битки лежат
    (мультисиг 4 из 5, люди в разных городах и даже странах)

    велком ту же нью волд, мухахаха))

     
     
  • 3.47, пох (?), 15:46, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а в чем проблема -то? Паяльник - он многоразовый.
     
  • 2.32, slauka (?), 15:43, 19/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и часто вам приходилось забывать свои пароли?
     
     
  • 3.44, OpenEcho (?), 01:09, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > и часто вам приходилось забывать свои пароли?

    Ни разу :)

    Помню всегда всего один единственный мастер пароль, который открывает менеджер паролей, который хранит все остальные пароли.

     
  • 2.36, Ordu (ok), 00:18, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется

    Тебе не приходилось забывать пароль? Помогает ли в этом случае паяльник?

     
     
  • 3.45, OpenEcho (?), 01:21, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Тебе не приходилось забывать пароль?

    Ни разу :)

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

    > Помогает ли в этом случае паяльник?

    Те, кто забывают СВОИ пароли, а потом брутфорсят, к ним не нужно применять паяльник, они сами себя наказали...

     
     
  • 4.48, пох (?), 15:47, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Помню всегда всего один единственный мастер пароль, который открывает мэнеджер паролей, который
    > хранит все остальные пароли.

    и если навернется база - тебе и рипер уже не поможет. А если авторы чудо-менеджера окажутся не совсем честными или не совсем аккуратными - тем ребятам рипер тоже не понадобится.

    Правильное решение, хвалю. Все яйца в одной корзинке.


     
     
  • 5.49, OpenEcho (?), 16:12, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > и если навернется база - тебе и рипер уже не поможет.

    Есть только две категории людей, те которые делают бэкап и те которые будут делать бэкап. Я из первой категории.

    > А если авторы чудо-менеджера окажутся не совсем честными или не совсем аккуратными
    > - тем ребятам рипер тоже не понадобится.

    Keepass опенсоурсный, хошь в перловке, хошь в крестах, a хошь и в шарпе и народ перепроверяет честность и аккуратность

    > Правильное решение, хвалю. Все яйца в одной корзинке.

    Вот именно, в одной корзине, а не на стикерах прикленных к экрану и не разбросанных где попало и у кого попало, что позволяет делать уникальные пароли в 128 символов к каждому ресурсу и не забывать их


     
     
  • 6.50, пох (?), 16:30, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Keepass опенсоурсный

    и? Кому и когда это помогало? :-(

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

    Причем если меня около стикера нет - можешь этим паяльником др..ть себе анус - хоть удовольствие получишь. Я-то вспомнить то, чего и не знал никогда, и бэкапа при себе нет - при всем желании сотрудничать - не смогу.

    Уборщица смахнула стикер в урну? Ну хрен с ним, взломаем снова. Это ж моя система, хочу - ломаю, не хочу - пароль не знаю.

     
  • 2.38, Аноним (38), 10:46, 20/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На себе проверял?
     
     
  • 3.46, OpenEcho (?), 01:24, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > На себе проверял?

    Только анониму с опенета могла прийти такая идея :)
    Вы правда все на себе проверяете ?

     
     
  • 4.52, InuYasha (?), 12:29, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а как иначе? Прежде чем делиться, должен протестить на себе, прогнать бенчмарки, оценить эргономику, выложить видосик ))))
     
     
  • 5.55, OpenEcho (?), 00:34, 31/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Яша, не много на себя берешь, кидая предьявы что я кому-то, что-то должен?

    Я бы преложил тебе поучаствовать в качестве взламываемого девайса для бенчмарков, но мне в отличии от тебя ничего от тебя не надо и ты мне ничего не должен, так что, обьективный бенчмарк не получится, a во вторых меня "пугают" чуваки желающие смотреть подобные сцены на видосиках, т.ч. отложим бенчмарки на добровольцах

     

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



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

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