forum.opennet.ru - "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" (52)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
Сообщение от opennews (?), 17-Май-19, 22:39
Выпущена (https://www.openwall.com/lists/announce/2019/05/14/1) новая версия старейшей поддерживаемой программы для подбора паролей John the Ripper 1.9.0-jumbo-1 (https://www.openwall.com/john/) (проект развивается с 1996 года). C выхода прошлой версии 1.8.0-jumbo-1 прошло 4.5 года, за которые было внесено более 6000 изменений (git commits) от более 80 разработчиков. В течение этого срока разработчики рекомендовали использовать текущую редакцию с GitHub (https://github.com/magnumripper/JohnTheRipper), состояние которой поддерживалось стабильным несмотря на вносимые изменения, благодаря непрерывной интеграции (https://github.com/claudioandre-br/packages#testing), включающей предварительную проверку каждого изменения (pull request) на многих платформах. Основной код проекта распространяется (https://github.com/magnumripper/JohnTheRipper/) под лицензией GPLv2+, а код некоторых компонентов под лицензией BSD. Особенностью новой версии является появление поддержки FPGA (в дополнение к CPU, GPU и Xeon Phi). Для плат ZTEX 1.15y (https://www.ztex.de/usb-fpga-1/usb-fpga-1.15y.e.html), включающих по 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 в расчете на плату, на цену оборудования и на ватт. Также поддерживаются кластеры (https://www.techsolvency.com/passwords/ztex/) из плат этого типа, что проверено вплоть до 16 плат (64 чипа FPGA), контролируемых с одного Raspberry Pi 2. Поддерживается обычная функциональность John the Ripper, включая все режимы подбора паролей и одновременную загрузку большого количества хешей. Для ускорения работы реализовано применение маски (режим "--mask", в том числе в комбинации с другими режимами) и сравнение вычисленных хешей с загруженными на стороне FPGA. С точки зрения реализации, во многих из дизайнов (например, для sha512crypt и Drupal7 (https://github.com/magnumripper/JohnTheRipper/tree/bleeding-...)) применены блоки состоящие из многопоточных процессорных ядер (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, соответственно. (Частично в рамках GSoC 2015.) - Многочисленные оптимизации для 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), применению непрерывной интеграции (сборки под десятки сочетаний операционной системы и компилятора и тестирование в них корректной поддержки всех форматов). URL: https://www.openwall.com/lists/announce/2019/05/14/1 Новость: https://www.opennet.dev/opennews/art.shtml?num=50702
Ответить \| Правка \| Cообщить модератору

Оглавление

Скажите кто может оценить Для приведённого формата хеша sha1 md5 p s какой , DHCPep (?), 22:39 , 17-Май-19, (1) –1

Подобные хеши кое-как составленные из небольшого количества вычислений быстрых , solardiz (ok), 23:02 , 17-Май-19, (2) +7

Ты ни черта не прав, кроме разве что быстрой криптографической функции Те же KDF, вот такая вот куйня (?), 02:00 , 18-Май-19, (5) +1

Про KDF ты в целом понимаешь правильно, а в моем комментарии упустил слова из н, solardiz (ok), 02:53 , 18-Май-19, (7) +2

поиск коллизий основа взлома хешей, хотел спросить (?), 11:54 , 18-Май-19, (18)

offtopic Даешь спор с автором риппера offtopic , пгуыыцрщ (?), 12:29 , 18-Май-19, (19) +1

таки да, поиск коллизий, Sw00p aka Jerom (?), 15:59 , 18-Май-19, (22) +1

да хоть 512 или 1024 бит, причем здесь биты если сам алгоритм дырявый коллизия , анон (?), 22:21 , 18-Май-19, (27) –2

чукча - не читатель, чукча - писатель ты может для начала пост прочтешь целиком , хотел спросить (?), 02:43 , 19-Май-19, (29) +1

А скажите пожалуйста Вот я так понимаю проблема хранения хеша пароля в виде bcr, Зябор (?), 14:01 , 19-Май-19, (30)

bcrypt предпочтительней в первую очередь из-за скорости вычисления - да к не, solardiz (ok), 15:38 , 19-Май-19, (31) +1

Спасибо за пояснения , Зябор (?), 16:59 , 19-Май-19, (33)
Ещё один возможно глупый вопрос, по этой же теме А вариант всё-таки хранения в , Зябор (?), 18:56 , 19-Май-19, (34) +1

Таких случаев, чтобы не было ресурсов на хоть насколько-то медленный хеш, вычисл, solardiz (ok), 21:46 , 19-Май-19, (35) +2

Спасибо , Зябор (?), 07:43 , 20-Май-19, (37)

Утверждение неверно И вот почему При совместной проверке обоих хэшей необхо, PnDx (ok), 11:58 , 20-Май-19, (39)

Предполагается, что основной хеш в данном контексте - bcrypt достаточно устойч, solardiz (ok), 13:42 , 20-Май-19, (40) +1

Да, в случае когда за приемлемое время решается задача подобрать все коллизии, PnDx (ok), 13:47 , 20-Май-19, (41)

Задача подобрать коллизии вот на эту функцию при подборе паролей обычно не ста, solardiz (ok), 14:11 , 20-Май-19, (42)

МД5 серьезно да хоть обзаворачивайся в 100500 уровней , анон (?), 22:19 , 18-Май-19, (26)

Достаточно ли моей рабочей машины из двух Xeon E5-2690v4 и GTX 1080 Ti для подбо, Алиса (??), 23:56 , 17-Май-19, (3) –2

достоверных дырок в AES-128 никто пока не находиллучшее что удалось это снизить , вот такая вот куйня (?), 02:13 , 18-Май-19, (6) +2
Эта тема почти не имеет отношения к JtR и новости, но всё же отвечу Зависит от т, solardiz (ok), 03:46 , 18-Май-19, (8) +4

Привет, Солар Немного не по теме, но не расскажешь какие ОС используешь дома д, Nightfall (?), 08:33 , 18-Май-19, (11) +2

Сильно не по теме, да и я не планировал давать интервью Это нарушение OPSEC, но, solardiz (ok), 18:32 , 18-Май-19, (24) +2

Нужно было использовать macOS как и все в Кремниевой долине , Ан.Зонд (?), 22:03 , 18-Май-19, (25) –1

Максим, эта формулировка звучит по-детски, убого и непрофессионально и, пока не , Аноним (10), 07:48 , 18-Май-19, (10) –4

Мы разработчики проводили тесты и мы говорим конкретно о нашей реализации в Jt, solardiz (ok), 15:46 , 18-Май-19, (21) +3

Очень хорошая прога, выручает часто, так как иногда забываю пароли, фирм обслужи, Aytishnik.com (ok), 09:52 , 18-Май-19, (12) +3

И не говори поди вспомни, где поставил 12345, где 54321, а где и вовсе qweasdzx, Аноним (14), 11:18 , 18-Май-19, (14) +2

блин да у тебя вообще феноменальная память Я такие сложные кроме, понятно, пе, пох (?), 11:44 , 18-Май-19, (16)

Вас, батенька, уволить надо за такую безопасность Пароли, которые подбираются з, Аноним (10), 11:41 , 18-Май-19, (15)

во-первых, тебя или твоего коллегу его клиенты уже уволили - и наняли дешевого а, пох (?), 11:48 , 18-Май-19, (17) +3

попридржи дубину-то Думаешь, первый оратор реально по сети пароли подбирает Да, InuYasha (?), 12:26 , 25-Май-19, (51)

ты будешь смеяться, но даже если не сам- то издевается над такими То есть это р, пох (?), 13:00 , 25-Май-19, (53)

Потребление 27 ватт офигеть, мой портативный 15 ваттный паяльник может гарант, OpenEcho (?), 14:52 , 18-Май-19, (20) +1

Во-первых, эти подходы имеют этические и юридические отличия Во-вторых, это друг, solardiz (ok), 16:03 , 18-Май-19, (23) +9

solardiz, дорогой, у Вас очень плохое чувство юмора , OpenEcho (?), 23:50 , 20-Май-19, (43) –1
Особенно обидно, когда третье происходит непосредственно во время перебора Как , Аноним (54), 13:27 , 27-Май-19, (54)

ну подбери своим паяльником пароль к кошельку где битки лежат мультисиг 4 из 5,, анон (?), 22:30 , 18-Май-19, (28) –1

а в чем проблема -то Паяльник - он многоразовый , пох (?), 15:46 , 21-Май-19, (47)

и часто вам приходилось забывать свои пароли , slauka (?), 15:43 , 19-Май-19, (32) +2

Ни разу Помню всегда всего один единственный мастер пароль, который открывает , OpenEcho (?), 01:09 , 21-Май-19, (44)

Тебе не приходилось забывать пароль Помогает ли в этом случае паяльник , Ordu (ok), 00:18 , 20-Май-19, (36) +2

Ни разу Помню всегда всего один единственный мастер пароль, который открывает , OpenEcho (?), 01:21 , 21-Май-19, (45)

и если навернется база - тебе и рипер уже не поможет А если авторы чудо-менедже, пох (?), 15:47 , 21-Май-19, (48) +1

Есть только две категории людей, те которые делают бэкап и те которые будут дела, OpenEcho (?), 16:12 , 21-Май-19, (49)

и Кому и когда это помогало - А стикер с моего экрана спереть - надо пройти н, пох (?), 16:30 , 21-Май-19, (50)

На себе проверял , Аноним (38), 10:46 , 20-Май-19, (38)

Только анониму с опенета могла прийти такая идея Вы правда все на себе проверя, OpenEcho (?), 01:24 , 21-Май-19, (46)

Ну а как иначе Прежде чем делиться, должен протестить на себе, прогнать бенчмар, InuYasha (?), 12:29 , 25-Май-19, (52)

Яша, не много на себя берешь, кидая предьявы что я кому-то, что-то должен Я бы п, OpenEcho (?), 00:34 , 31-Май-19, (55)

Сообщения [Сортировка по времени | RSS]

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

Сообщение от DHCPep (?), 17-Май-19, 22:39

Скажите кто может оценить. Для приведённого формата хеша sha1(md5($p).$s) какой должен быть длины пароль (минимум), чтобы перебор его был невозможен например для условного гугла за год.
Соль тут я так понимаю принципиального значения не имеет. Она же лишь для исключения словаря.
А также насколько адекватно хранение хеша пароля например такого
md5(md5($p).$s)
Тут же коллизию пароля хер подберёшь, ведь там ещё и соль?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +7 +/–

Сообщение от solardiz (ok), 17-Май-19, 23:02

Подобные хеши (кое-как составленные из небольшого количества вычислений быстрых хешей, также не предназначенных для паролей) - болезнь веб-приложений 2000-х, которая постепенно начала проходить в 2010-х. Ни одним из подобных способов хешировать пароли не следует. Для паролей следует использовать специально предназначенные хеши, такие как bcrypt, scrypt, yescrypt или Argon2. В веб-приложениях на PHP 5.5+, следует использовать интерфейс password_hash(): https://www.php.net/manual/en/function.password-hash.php
Длина пароля - лишь один из его параметров, хотя и очень важный, поэтому прямо на такой вопрос не ответишь, да и для некорректно выбранной хеш-функции вопрос не имеет практического смысла.
Соль не "лишь для исключения словаря", а выполняет несколько полезных функций сразу, но тут она и правда "принципиального значения не имеет" так как подобные хеши непригодны для паролей по другим причинам.
Вопрос про коллизии тем более не актуален по ряду причин.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от вот такая вот куйня (?), 18-Май-19, 02:00

Ты ни черта не прав, кроме разве что быстрой криптографической функции.
Те же KDF в том или ином виде используют хеш функции.
Короче рассказываю накой хрен нужны KDF:
1) сделать преобразование в хеш тяжелой операцией, особенно для всяких асиков, например PBKDF2 неплохо справляется (только не берите вариант SHA1, берите какую-нибудь SHA512 на всякий случай)
2) сделать не просто сложным расчет, а плохо параллелизуемым, этим способом пошли в Argon,там все упирается кол-во памяти. Но я пока не использую, потому что уже 3-ая версия вышла помимо Argon2i и Argon2d. А это все реализации, которых еще много на каких платформах нет (точнее есть, но недостаточно хороши для продакшена).
И да Argon использует крипто хеш-функцию Black2.
Которая внимание(!) - быстрее по утверждению самих авторов чем например SHA512.
--
Насчет кастомной KDF, многие не рекомендуют, НО чисто теоретически...
Если есть соль ты можешь сделать бесконечно много итераций (миллион например) типа "sha1(md5($p).$s)", но используя хотя бы SHA256:
n-times x SHA256(userkey + salt)
если n=3, то SHA256(SHA256(SHA256(userkey + salt) + salt) + salt)
тебе же надо хотя бы лям какой-нибудь
Только вот зачем это всё, если есть KDF, которые исследованы и их явно не дураки делали?
---
Теперь про соль... она используется для того, чтобы не дать использовать радужные таблицы, перед которыми прямой перебор тем же джоном или кэтом просто меркнет по скорости.
--
Конкретно по MD5, это 128-bit, что в теории больше времени жизни вселенной
НО!!!!
Вот эти ребята доказали возможность атаки, сложность которой 2^24.1.
https://www.win.tue.nl/hashclash/On%20Collisions%2...
Т.е. получается у нас энтропия резко снижается с 128 бит до 24.1
А это значит 17 981 374 вариантов перебираются за доли секунды.
Атака на SHA1 сложнее намного, но гугл сделал это за 100 000 USD на серверах AWS (гуглите shattered).
--
В случае sha1(md5($p).$s) соль тебе не поможет потому что это всего лишь одна итерация.
И соль это то, что известно атакуемому. Поэтому предложенная KDF "легко" трахнется радужными таблицами.
Атакующий просто найдет коллизию, которая даст тот же хеш, что и оригинальный пароль (либо это и будет сам оригинальный пароль).
--
Многое зависит от скорости перебора. Если сеть, то сложнее, может там банят на 10 минут после кадой третьей неудачной попытки. и всё приехали...
Другое дело если ты можешь организовать перебор в оффлайне )))

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от solardiz (ok), 18-Май-19, 02:53

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

18. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от хотел спросить (?), 18-Май-19, 11:54

> Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся.
поиск коллизий основа взлома хешей

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

19. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от пгуыыцрщ (?), 18-Май-19, 12:29

[offtopic] Даешь спор с автором риппера! [/offtopic]

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от Sw00p aka Jerom (?), 18-Май-19, 15:59

таки да, поиск коллизий

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

27. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –2 +/–

Сообщение от анон (?), 18-Май-19, 22:21

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

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

29. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от хотел спросить (?), 19-Май-19, 02:43

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Зябор (?), 19-Май-19, 14:01

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

31. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от solardiz (ok), 19-Май-19, 15:38

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

33. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Зябор (?), 19-Май-19, 16:59

Спасибо за пояснения.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от Зябор (?), 19-Май-19, 18:56

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

35. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от solardiz (ok), 19-Май-19, 21:46

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

37. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Зябор (?), 20-Май-19, 07:43

Спасибо!

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

39. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от PnDx (ok), 20-Май-19, 11:58

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

40. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от solardiz (ok), 20-Май-19, 13:42

Предполагается, что основной хеш (в данном контексте - bcrypt) достаточно устойчив к коллизиям, чтобы это не было проблемой. Вообще, коллизии в криптографических хешах - в частности, даже те что известны для MD5 и SHA-1 - обычно не являются проблемой при использовании этих хешей для паролей. (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и пропуск вычисления медленного) - очень серьезная проблема.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

41. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от PnDx (ok), 20-Май-19, 13:47

> (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении
> реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте
> выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и
> пропуск вычисления медленного) - очень серьезная проблема.
  Да, в случае когда за приемлемое время решается задача "подобрать все коллизии вот на эту функцию". MD5? Да, Вы правы.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

42. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от solardiz (ok), 20-Май-19, 14:11

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

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

26. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от анон (?), 18-Май-19, 22:19

МД5? серьезно? да хоть обзаворачивайся в 100500 уровней.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –2 +/–

Сообщение от Алиса (??), 17-Май-19, 23:56

Достаточно ли моей рабочей машины из двух Xeon E5-2690v4 и GTX 1080 Ti для подбора ключа к IP-core от Intel. Там, как понимаю, используется толи AES-128 то ли ещё какая-то подобная штука. Не очень понимаю в этих технологиях, просто хочу попробовать расшифровать исходный код, который закодирован вроде как AES-128.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от вот такая вот куйня (?), 18-Май-19, 02:13

достоверных дырок в AES-128 никто пока не находил
лучшее что удалось это снизить сложность до 2^126
а значит если нет возможности по сторонним каналам, а только прямым перебором
то тебе понадобится ~10^38 операций, что означает что если ты сможешь делать 1 триллион операций в секунду, то тебе все еще понадобится 10^26 секунд или
3,170,979,198,376,458,650 лет
так что про мамкиного хакера было прикольно )))

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +4 +/–

Сообщение от solardiz (ok), 18-Май-19, 03:46

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от Nightfall (?), 18-Май-19, 08:33

Привет, Солар. Немного не по теме, но не расскажешь какие ОС используешь дома (для персонального, частного пользования) и почему? Ты раньше был втянут, скажем так, во взаимодействие с андеграундом, у тебя брали вью во фраке и тп. , давным давно ты даже принимал участие во всяких хакерских е-зайнах, я помню твои эксплоиты кое-где. Поддержваешь ли ты какие-нибудь связи и как оцениваешь состояние так называемой "сцены"? Как ты относишься к вирусным технологиям в мире unix/linux (эта тема малопопулярна и мало исследованна, но что называется in the wild сейчас водятся несколько достаточно интересных экземпляров)?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

24. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от solardiz (ok), 18-Май-19, 18:32

Сильно не по теме, да и я не планировал давать интервью. Это нарушение OPSEC, но думаю уже не секрет что я использую QubesOS - делал с нее доклады, показывал USB passthrough как раз для доступа к ZTEX FPGA плате из VM'ки. На серверах всё еще наша Owl с дополнениями. Пока в целом полет нормальный, но устраивает не всё, да и системы устаревают. Не исключаю уход с Linux. Мой Phrack prophile еще достаточно свежий, от 2016 года - там я отвечаю на схожие вопросы про "сцену", так что если интересно, перечитай его. Не помню, чтобы я публиковал exploit'ы в e-zine'ах. Немного публиковал их в Bugtraq. Вирусы под Unix пока in the wild не встречал - видимо, у нас и наших клиентов не настолько стандартные настройки систем. Думаю, именно разнообразие систем и настроек сдерживает распространение вирусов под Unix-подобные системы.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

25. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –1 +/–

Сообщение от Ан.Зонд (?), 18-Май-19, 22:03

Нужно было использовать macOS как и все в Кремниевой долине.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

10. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –4 +/–

Сообщение от Аноним (10), 18-Май-19, 07:48

> что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее).
Максим, эта формулировка звучит по-детски, убого и непрофессионально и, пока не провели тесты, говорить о том, что the OpenCL implementation might be as fast as, or faster then the CUDA implementation on NVIDIA GPUs, рано.
// b.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +3 +/–

Сообщение от solardiz (ok), 18-Май-19, 15:46

Мы (разработчики) проводили тесты и мы говорим конкретно о нашей реализации в 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).

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +3 +/–

Сообщение от Aytishnik.com (ok), 18-Май-19, 09:52

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от Аноним (14), 18-Май-19, 11:18

И не говори: поди вспомни, где поставил 12345, где 54321, а где и вовсе qweasdzxc…

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от пох (?), 18-Май-19, 11:44

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Аноним (10), 18-Май-19, 11:41

Вас, батенька, уволить надо за такую безопасность. Пароли, которые подбираются за вменяемое время - это не пароли, а шутка юмора.
// b.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +3 +/–

Сообщение от пох (?), 18-Май-19, 11:48

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

51. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от InuYasha (?), 25-Май-19, 12:26

попридржи дубину-то )
Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

53. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от пох (?), 25-Май-19, 13:00

> Думаешь, первый оратор реально по сети пароли подбирает? Да нет конечно.
ты будешь смеяться, но даже если не сам-  то издевается над такими.
То есть это реальная и регулярная проблема обслуживающих микролавочки с полутора инвалидами - то сами в виду бардака "кто это настраивал три года назад? Вася? Вася под каток попал еще год тому, все пароли пропали!" то между их визитами кто-то еще успел "поработать".
Ну а поскольку пароли обычно не идут дальше "win123456" - то подобрать их удается за вполне конечное время (самый херовый - фио и мабила "настройщика обоев". Поскольку как его звали никто не помнит, да и номера тоже, а пароль длинный).
Причем тут "по сети"? Локально он их подбирает, скопировав юзербазку любимым линуксом.
На fpga, понятен, у таких денег не наберется, да им и не надо. В конце-концов, ненадолго выключат майнилку - и подберут на своей нвидии.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

20. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от OpenEcho (?), 18-Май-19, 14:52

Потребление 27 ватт... офигеть, мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +9 +/–

Сообщение от solardiz (ok), 18-Май-19, 16:03

Во-первых, эти подходы имеют этические и юридические отличия.

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

43. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –1 +/–

Сообщение от OpenEcho (?), 20-Май-19, 23:50

> Во-первых, эти подходы имеют этические и юридические отличия.
solardiz, дорогой, у Вас очень плохое чувство юмора...

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

54. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Аноним (54), 27-Май-19, 13:27

Особенно обидно, когда третье происходит непосредственно во время перебора. Как говорится, "Вскрытие показало, что больной умер от вскрытия"

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

28. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" –1 +/–

Сообщение от анон (?), 18-Май-19, 22:30

ну подбери своим паяльником пароль к кошельку где битки лежат
(мультисиг 4 из 5, люди в разных городах и даже странах)
велком ту же нью волд, мухахаха))

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

47. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от пох (?), 21-Май-19, 15:46

а в чем проблема -то? Паяльник - он многоразовый.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

32. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от slauka (?), 19-Май-19, 15:43

и часто вам приходилось забывать свои пароли?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

44. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от OpenEcho (?), 21-Май-19, 01:09

> и часто вам приходилось забывать свои пароли?
Ни разу :)
Помню всегда всего один единственный мастер пароль, который открывает менеджер паролей, который хранит все остальные пароли.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

36. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +2 +/–

Сообщение от Ordu (ok), 20-Май-19, 00:18

> мой портативный 15 ваттный паяльник может гарантированно выбивать из любого самые сложные пароли и за очень малое время, аss rippеr называется
Тебе не приходилось забывать пароль? Помогает ли в этом случае паяльник?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

45. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от OpenEcho (?), 21-Май-19, 01:21

> Тебе не приходилось забывать пароль?
Ни разу :)
Помню всегда всего один единственный мастер пароль, который открывает мэнеджер паролей, который хранит все остальные пароли.
Лет десять пользую кросплатформеный KeepAss, а раньше юзал обычный запароленный архив с текстовыми файлами
> Помогает ли в этом случае паяльник?
Те, кто забывают СВОИ пароли, а потом брутфорсят, к ним не нужно применять паяльник, они сами себя наказали...

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

48. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +1 +/–

Сообщение от пох (?), 21-Май-19, 15:47

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

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

49. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от OpenEcho (?), 21-Май-19, 16:12

> и если навернется база - тебе и рипер уже не поможет.
Есть только две категории людей, те которые делают бэкап и те которые будут делать бэкап. Я из первой категории.
> А если авторы чудо-менеджера окажутся не совсем честными или не совсем аккуратными
> - тем ребятам рипер тоже не понадобится.
Keepass опенсоурсный, хошь в перловке, хошь в крестах, a хошь и в шарпе и народ перепроверяет честность и аккуратность
> Правильное решение, хвалю. Все яйца в одной корзинке.
Вот именно, в одной корзине, а не на стикерах прикленных к экрану и не разбросанных где попало и у кого попало, что позволяет делать уникальные пароли в 128 символов к каждому ресурсу и не забывать их

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

50. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от пох (?), 21-Май-19, 16:30

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

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

38. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от Аноним (38), 20-Май-19, 10:46

На себе проверял?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

46. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от OpenEcho (?), 21-Май-19, 01:24

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

52. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от InuYasha (?), 25-Май-19, 12:29

Ну а как иначе? Прежде чем делиться, должен протестить на себе, прогнать бенчмарки, оценить эргономику, выложить видосик ))))

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

55. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA" +/–

Сообщение от OpenEcho (?), 31-Май-19, 00:34

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

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	–1 +/–
Сообщение от DHCPep (?), 17-Май-19, 22:39
Скажите кто может оценить. Для приведённого формата хеша sha1(md5($p).$s) какой должен быть длины пароль (минимум), чтобы перебор его был невозможен например для условного гугла за год. Соль тут я так понимаю принципиального значения не имеет. Она же лишь для исключения словаря. А также насколько адекватно хранение хеша пароля например такого md5(md5($p).$s) Тут же коллизию пароля хер подберёшь, ведь там ещё и соль?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+7 +/–
	Сообщение от solardiz (ok), 17-Май-19, 23:02
	Подобные хеши (кое-как составленные из небольшого количества вычислений быстрых хешей, также не предназначенных для паролей) - болезнь веб-приложений 2000-х, которая постепенно начала проходить в 2010-х. Ни одним из подобных способов хешировать пароли не следует. Для паролей следует использовать специально предназначенные хеши, такие как bcrypt, scrypt, yescrypt или Argon2. В веб-приложениях на PHP 5.5+, следует использовать интерфейс password_hash(): https://www.php.net/manual/en/function.password-hash.php Длина пароля - лишь один из его параметров, хотя и очень важный, поэтому прямо на такой вопрос не ответишь, да и для некорректно выбранной хеш-функции вопрос не имеет практического смысла. Соль не "лишь для исключения словаря", а выполняет несколько полезных функций сразу, но тут она и правда "принципиального значения не имеет" так как подобные хеши непригодны для паролей по другим причинам. Вопрос про коллизии тем более не актуален по ряду причин.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	5. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от вот такая вот куйня (?), 18-Май-19, 02:00
	Ты ни черта не прав, кроме разве что быстрой криптографической функции. Те же KDF в том или ином виде используют хеш функции. Короче рассказываю накой хрен нужны KDF: 1) сделать преобразование в хеш тяжелой операцией, особенно для всяких асиков, например PBKDF2 неплохо справляется (только не берите вариант SHA1, берите какую-нибудь SHA512 на всякий случай) 2) сделать не просто сложным расчет, а плохо параллелизуемым, этим способом пошли в Argon,там все упирается кол-во памяти. Но я пока не использую, потому что уже 3-ая версия вышла помимо Argon2i и Argon2d. А это все реализации, которых еще много на каких платформах нет (точнее есть, но недостаточно хороши для продакшена). И да Argon использует крипто хеш-функцию Black2. Которая внимание(!) - быстрее по утверждению самих авторов чем например SHA512. -- Насчет кастомной KDF, многие не рекомендуют, НО чисто теоретически... Если есть соль ты можешь сделать бесконечно много итераций (миллион например) типа "sha1(md5($p).$s)", но используя хотя бы SHA256: n-times x SHA256(userkey + salt) если n=3, то SHA256(SHA256(SHA256(userkey + salt) + salt) + salt) тебе же надо хотя бы лям какой-нибудь Только вот зачем это всё, если есть KDF, которые исследованы и их явно не дураки делали? --- Теперь про соль... она используется для того, чтобы не дать использовать радужные таблицы, перед которыми прямой перебор тем же джоном или кэтом просто меркнет по скорости. -- Конкретно по MD5, это 128-bit, что в теории больше времени жизни вселенной НО!!!! Вот эти ребята доказали возможность атаки, сложность которой 2^24.1. https://www.win.tue.nl/hashclash/On%20Collisions%2... Т.е. получается у нас энтропия резко снижается с 128 бит до 24.1 А это значит 17 981 374 вариантов перебираются за доли секунды. Атака на SHA1 сложнее намного, но гугл сделал это за 100 000 USD на серверах AWS (гуглите shattered). -- В случае sha1(md5($p).$s) соль тебе не поможет потому что это всего лишь одна итерация. И соль это то, что известно атакуемому. Поэтому предложенная KDF "легко" трахнется радужными таблицами. Атакующий просто найдет коллизию, которая даст тот же хеш, что и оригинальный пароль (либо это и будет сам оригинальный пароль). -- Многое зависит от скорости перебора. Если сеть, то сложнее, может там банят на 10 минут после кадой третьей неудачной попытки. и всё приехали... Другое дело если ты можешь организовать перебор в оффлайне )))
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	7. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от solardiz (ok), 18-Май-19, 02:53
	Про KDF ты в целом понимаешь правильно, а в моем комментарии упустил слова "из небольшого количества вычислений". Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся. Про "меркнет по скорости" перед rainbow tables не так просто - тут влияет много факторов. А соль начали использовать до появления rainbow tables (1970-е vs. 1990-е), так что предназначена она была не непосредственно против них, да и сейчас несет несколько функций.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	18. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от хотел спросить (?), 18-Май-19, 11:54
	> Упомянутые тобой атаки на MD5 и SHA-1 к теме не относятся. поиск коллизий основа взлома хешей
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	19. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от пгуыыцрщ (?), 18-Май-19, 12:29
	[offtopic] Даешь спор с автором риппера! [/offtopic]
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	22. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 18-Май-19, 15:59
	таки да, поиск коллизий
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	27. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	–2 +/–
	Сообщение от анон (?), 18-Май-19, 22:21
	>Конкретно по MD5, это 128-bit, что в теории больше времени жизни вселенной да хоть 512 или 1024 бит, причем здесь биты если сам алгоритм дырявый? коллизия к твоим 128 битам на обычных процах у МД5 находиться за время.... сюрпрайз МИНУТЫ!!!
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	29. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от хотел спросить (?), 19-Май-19, 02:43
	чукча - не читатель, чукча - писатель? ты может для начала пост прочтешь целиком?
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	30. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от Зябор (?), 19-Май-19, 14:01
	А скажите пожалуйста. Вот я так понимаю проблема хранения хеша пароля в виде bcrypt предпочтительней в первую очередь из-за скорости вычисления, что приводит например в случае утекания базы хешей, к неподъёмному времени взлома. Но опять же и проверка введённых пользователем регистрационных данных замедляется соответствующим образом, что например даёт путь для напряга сервера подачей потока вариантов введённых данных. Тут или городить капчи, или бороться с кол-вом коннектов в единицу времени. А скажите насколько допустим такой например двух-этапный способ, когда например в БД хранить вариант bcrypt'а, а вместе с тем ещё хеш например substr(md5($u.$s.$p)), 0, 8) и сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом? Или это просто дикий костыль?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	31. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от solardiz (ok), 19-Май-19, 15:38
	"bcrypt предпочтительней в первую очередь из-за скорости вычисления" - да. "к неподъёмному времени взлома" - это зависит еще и от выбора паролей. "Тут или городить капчи, или бороться с кол-вом коннектов в единицу времени." - да, но еще нужно учесть что у сервиса и до внедрения "тяжелого" хеширования паролей почти наверняка были другие аналогичные с точки зрения риска DoS слабые места, так что чтобы не сделать сервер более уязвимым к DoS достаточно настроить хеш так, чтобы он не был медленнее обработки другого самого медленного запроса, также доступного до аутентификации. Например, переход с быстрого не-парольного хеша вроде MD5, занимавшего 1 микросекунду, на bcrypt, настроенный на время 10 ms, на типичном веб-сервисе не повысит уязвимость к DoS (зачастую найдутся и другие запросы, занимающие 10+ ms или требующие больше I/O), но замедлит подбор паролей по украденным хешам на порядки. А с DoS можно бороться отдельно, для всех типов запросов. "сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	33. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от Зябор (?), 19-Май-19, 16:59
	Спасибо за пояснения.
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	34. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от Зябор (?), 19-Май-19, 18:56
	Ещё один возможно глупый вопрос, по этой же теме. А вариант всё-таки хранения в БД "быстрого" хеша вдобавок к "правильному". Но этот "быстрый" если допустим формируется "чёрным ящиком"? Я тут понимаю, что в случае "чёрного ящика" - при компроментации сервера и этот чёрный ящик становится тоже доступен атакующему. Но если пойти дальше и "чёрный ящик" сделать действительно таковым, т.е. отдельно от серверов на которых крутится сервис иметь выделенный сервер на который при регистрации/смене пароля отправляются данные для формирования этого "быстрого" хеша непонятного способа формирования, и при авторизации отправляются данные для проверки его же. И уже в случае положительного ответа - проверяется "правильный" хеш. Ну и соответственно этот "чёрный ящик" при компроментации самого сервиса - не становится доступен атакующему и он так-же в случае отказа или кто-то вместо него условно поставил свой всегда дающий "истину" на запросы авторизации, не даёт возможности авторизации т.к. в этом случае всё равно проверяется "правильный" хеш. Велосипед?
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	35. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от solardiz (ok), 19-Май-19, 21:46
	Таких случаев, чтобы не было ресурсов на хоть насколько-то медленный хеш, вычисляемый всегда, не бывает. Всегда можно, например, заменить микросекунду на миллисекунду без заметного ущерба для производительности всего сервиса. Поэтому хранить не-парольный быстрый хеш совершенно ни к чему. Если есть ресурсы на внедрение черного ящика (и не одного - для отказоустойчивости), то тем более они есть и на медленный хеш. Эти вещи хорошо использовать вместе - см. слайды от https://www.openwall.com/presentations/Passwords12-The-Futur... и далее (а можно и предыдущие тоже) и реализацию https://github.com/SUNET/VCCS. Там используется HMAC на HSM поверх вычисляемого на обычном сервере медленного хеша, хотя есть определенные преимущества (а в некоторых случаях и недостатки) использования вместо этого обратимого шифрования "черным ящиком" медленных хешей, вычисленных на обычном сервере. Мы (Openwall) консультируем по таким внедрениям, так что если интересует всерьез - обращайтесь. Хранить и проверять еще и какой-то более "правильный" хеш, не требующий "черного ящика", при этом не следует. Это лишь снижает пользу от применения "черного ящика". Насчет "поставил свой всегда дающий "истину" на запросы авторизации" - "черный ящик" не должен отвечать да/нет (он и не может - у него нет доступа к БД), а лишь довычислять или шифровать хеши.
	Ответить \| Правка \| ^ к родителю #34 \| Наверх \| Cообщить модератору


	37. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от Зябор (?), 20-Май-19, 07:43
	Спасибо!
	Ответить \| Правка \| ^ к родителю #35 \| Наверх \| Cообщить модератору


	39. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от PnDx (ok), 20-Май-19, 11:58
	> "сперва проверять md5 вариант, если он корректен, то уже делать проверку bcrypt'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует. Утверждение неверно. И вот почему: При совместной проверке обоих хэшей необходимо предоставлять вектор (строку), для которого обе проверки валидны. Т.о., атакующий должен вместо подбора первой попавшейся коллизии найти пересечение на множествах коллизий обеих функций. Которое в "плохом" сценарии вообще может оказаться единственным. Но даже в "хорошем" случае решение задачи никогда не будет легче подбора коллизии на самый "сильный" хэш из пары.
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	40. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от solardiz (ok), 20-Май-19, 13:42
	Предполагается, что основной хеш (в данном контексте - bcrypt) достаточно устойчив к коллизиям, чтобы это не было проблемой. Вообще, коллизии в криптографических хешах - в частности, даже те что известны для MD5 и SHA-1 - обычно не являются проблемой при использовании этих хешей для паролей. (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и пропуск вычисления медленного) - очень серьезная проблема.
	Ответить \| Правка \| ^ к родителю #39 \| Наверх \| Cообщить модератору


	41. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от PnDx (ok), 20-Май-19, 13:47
	> (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении > реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте > выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и > пропуск вычисления медленного) - очень серьезная проблема. Да, в случае когда за приемлемое время решается задача "подобрать все коллизии вот на эту функцию". MD5? Да, Вы правы.
	Ответить \| Правка \| ^ к родителю #40 \| Наверх \| Cообщить модератору


	42. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от solardiz (ok), 20-Май-19, 14:11
	Задача "подобрать коллизии вот на эту функцию" при подборе паролей обычно не ставится. Это не рационально. Вместо этого проверяются вероятные пароли. Чтобы задача именно подбора коллизий оказалась актуальной, хеш-функция должна быть очень плохой - никогда не предназначавшейся в качестве криптографической или с фатальной ошибкой в реализации.
	Ответить \| Правка \| ^ к родителю #41 \| Наверх \| Cообщить модератору


	26. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от анон (?), 18-Май-19, 22:19
	МД5? серьезно? да хоть обзаворачивайся в 100500 уровней.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

3. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	–2 +/–
Сообщение от Алиса (??), 17-Май-19, 23:56
Достаточно ли моей рабочей машины из двух Xeon E5-2690v4 и GTX 1080 Ti для подбора ключа к IP-core от Intel. Там, как понимаю, используется толи AES-128 то ли ещё какая-то подобная штука. Не очень понимаю в этих технологиях, просто хочу попробовать расшифровать исходный код, который закодирован вроде как AES-128.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	6. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от вот такая вот куйня (?), 18-Май-19, 02:13
	достоверных дырок в AES-128 никто пока не находил лучшее что удалось это снизить сложность до 2^126 а значит если нет возможности по сторонним каналам, а только прямым перебором то тебе понадобится ~10^38 операций, что означает что если ты сможешь делать 1 триллион операций в секунду, то тебе все еще понадобится 10^26 секунд или 3,170,979,198,376,458,650 лет так что про мамкиного хакера было прикольно )))
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	8. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+4 +/–
	Сообщение от solardiz (ok), 18-Май-19, 03:46
	Эта тема почти не имеет отношения к 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/documen... Мне непонятно, какой моделью угроз руководствовались авторы статьи и CERT. Если верно моё понимание, что ключ всё равно в какой-то момент оказывается в памяти компьютера, на котором работает EDA (см. "Figure 3: Work flow of the P1735 standard." в статье), то его оттуда можно просто извлечь. Авторы и CERT "не слышали" про reverse-engineering и анализ памяти приложения или же считают, что атакующие почему-то ограничатся какими-то "более этичными" или не нарушающими какие-то юридические условия способами? Странно. Но тем не менее, статья, похоже, о том как даже не прибегая к тому чтобы посто подсмотреть ключ, всё равно можно расшифровать через oracles.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	11. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от Nightfall (?), 18-Май-19, 08:33
	Привет, Солар. Немного не по теме, но не расскажешь какие ОС используешь дома (для персонального, частного пользования) и почему? Ты раньше был втянут, скажем так, во взаимодействие с андеграундом, у тебя брали вью во фраке и тп. , давным давно ты даже принимал участие во всяких хакерских е-зайнах, я помню твои эксплоиты кое-где. Поддержваешь ли ты какие-нибудь связи и как оцениваешь состояние так называемой "сцены"? Как ты относишься к вирусным технологиям в мире unix/linux (эта тема малопопулярна и мало исследованна, но что называется in the wild сейчас водятся несколько достаточно интересных экземпляров)?
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	24. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от solardiz (ok), 18-Май-19, 18:32
	Сильно не по теме, да и я не планировал давать интервью. Это нарушение OPSEC, но думаю уже не секрет что я использую QubesOS - делал с нее доклады, показывал USB passthrough как раз для доступа к ZTEX FPGA плате из VM'ки. На серверах всё еще наша Owl с дополнениями. Пока в целом полет нормальный, но устраивает не всё, да и системы устаревают. Не исключаю уход с Linux. Мой Phrack prophile еще достаточно свежий, от 2016 года - там я отвечаю на схожие вопросы про "сцену", так что если интересно, перечитай его. Не помню, чтобы я публиковал exploit'ы в e-zine'ах. Немного публиковал их в Bugtraq. Вирусы под Unix пока in the wild не встречал - видимо, у нас и наших клиентов не настолько стандартные настройки систем. Думаю, именно разнообразие систем и настроек сдерживает распространение вирусов под Unix-подобные системы.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	25. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	–1 +/–
	Сообщение от Ан.Зонд (?), 18-Май-19, 22:03
	Нужно было использовать macOS как и все в Кремниевой долине.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору

10. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	–4 +/–
Сообщение от Аноним (10), 18-Май-19, 07:48
> что ничуть не мешает полноценному использованию GPU от NVIDIA (и даже помогает, благодаря фокусированию разработки и оптимизаций на одну реализацию каждого формата под GPU вместо двух реализаций ранее). Максим, эта формулировка звучит по-детски, убого и непрофессионально и, пока не провели тесты, говорить о том, что the OpenCL implementation might be as fast as, or faster then the CUDA implementation on NVIDIA GPUs, рано. // b.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	21. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+3 +/–
	Сообщение от solardiz (ok), 18-Май-19, 15:46
	Мы (разработчики) проводили тесты и мы говорим конкретно о нашей реализации в 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).
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору

12. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+3 +/–
Сообщение от Aytishnik.com (ok), 18-Май-19, 09:52
Очень хорошая прога, выручает часто, так как иногда забываю пароли, фирм обслуживаю много, поди вспомни какой пароль пять лет назад ставил. Вот и выручает каждый месяц. Спасибо разработчикам.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	14. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+2 +/–
	Сообщение от Аноним (14), 18-Май-19, 11:18
	И не говори: поди вспомни, где поставил 12345, где 54321, а где и вовсе qweasdzxc…
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору