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

Выпуск 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]

	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 | Индекс форумов | Темы | Пред. тема | След. тема