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

Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA, opennews (?), 17-Май-19, (0) [смотреть все] Скажите кто может оценить Для приведённого формата хеша sha1 md5 p s какой , DHCPep (?), 22:39 , 17-Май-19, (1) –1 // Подобные хеши кое-как составленные из небольшого количества вычислений быстрых , solardiz (ok), 23:02 , 17-Май-19, (2) +6   // Ты ни черта не прав, кроме разве что быстрой криптографической функции Те же 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) +7 // 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) 1,3,10,12,20

Сообщения

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

	2. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+6 +/–
	Сообщение от 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 Длина пароля - лишь один из его параметров, хотя и очень важный, поэтому прямо на такой вопрос не ответишь, да и для некорректно выбранной хеш-функции вопрос не имеет практического смысла. Соль не "лишь для исключения словаря", а выполняет несколько полезных функций сразу, но тут она и правда "принципиального значения не имеет" так как подобные хеши непригодны для паролей по другим причинам. Вопрос про коллизии тем более не актуален по ряду причин.
	Ответить | Правка | Наверх | 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 минут после кадой третьей неудачной попытки. и всё приехали... Другое дело если ты можешь организовать перебор в оффлайне )))
	Ответить | Правка | Наверх | 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-е), так что предназначена она была не непосредственно против них, да и сейчас несет несколько функций.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	22. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+1 +/–
	Сообщение от Sw00p aka Jerom (?), 18-Май-19, 15:59
	таки да, поиск коллизий
	Ответить | Правка | Наверх | 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
	чукча - не читатель, чукча - писатель? ты может для начала пост прочтешь целиком?
	Ответить | Правка | Наверх | 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'ом" - это бессмысленно, так как атакующий сделает то же самое и получит не меньшее ускорение. Быстрый хеш, даже усеченный, хранить не следует.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от Зябор (?), 19-Май-19, 16:59
	Спасибо за пояснения.
	Ответить | Правка | Наверх | 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) консультируем по таким внедрениям, так что если интересует всерьез - обращайтесь. Хранить и проверять еще и какой-то более "правильный" хеш, не требующий "черного ящика", при этом не следует. Это лишь снижает пользу от применения "черного ящика". Насчет "поставил свой всегда дающий "истину" на запросы авторизации" - "черный ящик" не должен отвечать да/нет (он и не может - у него нет доступа к БД), а лишь довычислять или шифровать хеши.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск John the Ripper 1.9.0-jumbo-1 с поддержкой FPGA"	+/–
	Сообщение от Зябор (?), 20-Май-19, 07:43
	Спасибо!
	Ответить | Правка | Наверх | 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 - обычно не являются проблемой при использовании этих хешей для паролей. (Чтобы это стало проблемой, коллизии должны были бы проявляться в отношении реальных паролей.) Реальной проблемой является быстрота вычисления таких хешей. В контексте выше, упомянутое мной ускорение подбора через проверку сначала быстрого хеша (и пропуск вычисления медленного) - очень серьезная проблема.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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