В рамках эксперимента, предложенного в видео, нужно написать фразу на английском языке состояющую ровно из 16 символов (включая знаки препинания). Давайте посмотрим сколько фраз, подходящих под это условие, сходу придет на ум. 1:21 что такое Хэш 3:43 коллизии 4:38 классификация Хэш функций 6:10 парадокс дней рождений 8:30 функции формирования ключа 9:13 как борются с коллизиями 9:46 брутфорс 15:21 хэш таблицы 17:11 радужные таблицы 21:46: выводы
я помню как хороший товарищ-реверсер всего парой фраз объяснил максимально просто почему в любом хеше есть коллизия: "просто потому, что хеширование - отображение бесконечного множества конечным" :)
Все абсолютно верно, только для современных хэш-функций начиная c SHA256 общее количество возможных хешей настолько огромное, что до сих пор неизвестна ни одна коллизия - чтобы две разные строки давали одинаковый хэш и потом и считается что данным феноменом можно пренебречь, а так ты конечно же абсолютно прав. Если произвольной длины информация сжимается всего в 32 байта то разумеется дубли обязаны быть
Знаю, что видео старое, просто хотел поглумиться над сбербанком, у которого недавно выяснилось, что они хранят пароли пользователей в открытом виде, мотивируя это тем, что это для того, чтоб пароли были регистронезависимыми, чтоб пользователям было удобно. фэйс палм.
немного в тему применения соли для простых пользователей. чтобы не записывать и не сохранять пароли в браузерах я как параноик использую следующий способ. Придумываем парольную фразу. которую легко запомнить. и которую можно даже записать. придумываем ее по принципу {прилагательное} {существительное} {глагол} например "быстрый конь бежит". далее берем по 3 первых символа от каждого слова (бысконбеж) и вводим русскими буквами в английской раскладки получается ",scrjy,t;" добавляем статическую соль например виде (){} или знаков препинания, цифр. "{,scrjy,t;}","*,scrjy,t;*","321,scrjy,t123". далее добавляем динамическую соль формируя ее в зависимости от домена сайта например беря первую и последнюю букву домена. например для yandex.ru => yx для vk.com => vk. это нужно чтобы на различных сайтах пароли были различными. так для yandex.ru пароль будет "y{,scrjy,t;}x", для vk.com => "v{,scrjy,t;}k", для somedomen => "s{,scrjy,t;}n"
Идея хорошая, но недоработанная. Все пароли имеют 1 шаблон, различаются первым и последним символом... Ну, так себе паранойя. Здесь вся хитрость в алгоритме, а если утянуть один пароль, то при знании алгоритма построения пароля, все другие компроментируются автоматом. А мы знаем, что одна из основ безопасности - в секрете хранится должен пароль, а алгоритм может быть публичным. Гораздо лучше такая связка: Имеется секретное слово (мастер-пароль), который используется лишь для генерации всех паролей. От связки (мастер_пароль + название_сайта) берется хеш, и пропускается через base64. И там уже берется подстрока нужной длины (10, 12, 16...) символов. Например: Секретное слово "Pa$$w0rd" :) Сайты те же, yandex.ru и vk.com На сайте approsto.com/sha-generator/ забиваем Pa$$w0rd yandex.ru для SHA512 base64 hash получается строка "ZC5webUTKgAJzEpHULS2hfF5mkP20Ud........." А для Pa$$w0rd vk.com получается строка "niUZs2imqS1lV7xGULULVRA3Z7tsiX/eHz........." Так же намного лучше, никаких общих подстрок между паролями. Менять их "оптом" тоже несложно: К связке мастер_пароль + название_сайта добавляется дата изменения, например "Pa$$w0rd 16.10.2019 yandex.ru" Причем строку "16.10.2019 yandex.ru" можно хоть на рабочем столе в txt хранить, хоть в облаке - без мастер пароля от нее мало пользы. Через месяц надо сменить пароль - поменял строку на "Pa$$w0rd 16.11.2019 yandex.ru", получил АБСОЛЮТНО новый пароль, который не нужно запоминать. )) Единственное, для бОльшей секьюрности можно не пользоваться approsto.com/sha-generator/ и прочими онлайн сервисами, а использовать доверенное приложение для PC/телефона (такие вообще есть??) или написать самостоятельно )) Как-то так.
FF неплохо шифрует пароли и если вы забудете свой пароль, которым зашифровали базу, то вы никогда её не расшифруйте, а лучший пароль - это тот, который ничего не значит, ни с чем не ассоциируется и не имеет никакого смысла. Просто один раз сгенерируйте себе такой мастер-пароль, заучите его наизусть и забудьте про все сложности и паранойю.
ответ: show_must_Go-On! Это-же не крипто хэш, крипто хэши не обратимы, только если найти коллизии на каждый символ, что на лету почти не возможно. что касается алгоритма поиска коллизий, то такие инструменты пишут обычно сами. Брут Форс сейчас не в моде, обычно хорошо работает обход, а не взлом.
Больше всего мне понравилось в этом видео, что я не узнал ничего нового. Значит у меня не все так плохо, спасибо книгам Таненбаума! А так, видео реально полезное.
12:19 можно просто нагенерить бесконечное количество пароль используя один и тот же алгоритм и возможно какие-то из этих комбинаций смогут пригодится еще где-то =)
Мне как-то один джавист лайфхак подсказал для формирования своих паролей. Использовать слова из старорусского на латиннице, которые уже не используются, или из других очень редких для it языков, вроде татарского или чукотского. Плюс его писать с большой буквы, дальше полую дату своего рождения в 16ричной системе (лучше ее запомнить как константу), и в конце поставить точку
было дело, подогревал интерес к технологиям, изучая хацкерские инструменты. и вот что сказать накопилось) самый лучший способ хеширования - неизвестный хакеру, недоступный в hashcat, john the ripper и аналогах, сложный и долгий для просчета. bcrypt хорош - но прожорлив. sha512 неплох, но считается в разы быстрее. мне нравится PBKDF2-HMAC-SHA256/512. среднячок в соотношении расход ресурсов к времени брутфорса. если исходный код хеширования пароля недоступен хакеру - 2-3 простейших действия сведут любой брутфорс на нет. удалите 3-й и 12-й символ, поменяйте какие то символы местами. используйте дополнительно статичную соль. в итоге - в бд нет соли, у хакера нет полного алгоритма, да и софт для брутфорса говорит, что таких хешей он не знает. насчет недоступности мощностей - это вы зря. всегда есть возможность заказать брут хеша в интернетах. причем с оплатой за решенный хеш. вообще в бруте паролей с sql дампов цели 2 - компрометация паролей обычных юзеров, в надежде, что они используют тот же пароль в указанной почте. и никто не станет считать 72^9 паролей для каждого юзера. тут обычно по словарю подбор ведут. либо компрометация пароля админа, модератора etc.(тут можно и брут юзать) но эта проблема неплохо решается сокрытием страницы входа. ограничением входа по ip, useragent, 2-х факторке. есть вот случай. blind and time based sql inj. полный дамп username:password. включая пароль админа. брут md5(md5($pass)) для админа занял на 1060TI 4 дня. Night1988)) и чтобы вы думали? за месяц брутфорса не нашел админ панель))
Только вот что я не пойму - в большинстве случаев-то у взломщика нет доступа к хешу т.к. он храниться где-то в базе данных, которую он собирается взломать. Ткчт эти способы взлома в большинстве случаев не помогут или я чего-то не понимаю?
Привет! На тебе окуляры с "технологией" Blue Block? Расскажи что-то о них: где покупал? за сколько? стоит ли использовать в работе? глаза меньше устают? когда надеваешь? можно ли использовать в быту (например, во время вождения автомобиля)?
у него уже было видео про эти очки, точно название не помню, но думаю поиском по каналу по слову "очки" найдется. Суть таких очков в цветофильтре голубого, которого с избытком излучают светодиоды с холодным светом, тем самым снижается напряжение на сетчатку от подсветки монитора. Ну и по личным ощущениям, я стал лучше различать оттенки с монитора, после того как одел очки с таким фильтром, хотя возможно это особенности моего остигматизма, ибо менять очки я пошел, когда понадобились другие диоптрии.
Ох нет только не md5. Однажды я забыл пароль от админки сайта и с помощью базы данных к которой имел доступ вытащил пароль в md5 формате, через прогу которая подбирает md5 хэш, работала (вычисления делала) она кстати на gpu, так как там вычисления были быстрее. Итог, за 2 минуты подобрал свой пароль)
Archangel но если база доступна была не только на чтение, то можно было бы вставить хеш от 123456 и войти, а потом сменить пароль :D (ну или просто сменить на хеш нового)
@@ГошаАввакумов-к1т Сам так делал. Как-никак админ всё же и доступ к базе имелся. Но прокатывает не всегда, но не в этом случае. Хорошо когда знаешь как получаются хэши движком. Видел самописный движок с двойным прогоном пароля по функциям.
@@igornatale C: 1) отсутсвует ооп; 2) нигде не используется; 3) старый; 4) сложный; 5) безполезен в эпоху пайтхона и высокоуровневых языков програмирования;
@@unknown-vq1gjа драйвера разве не на с пишут? C как я помню функциональный. И ООП и функциональный имеют свою плюсы и минусы 2) драйвера вроде как на с пишутся 3) для кого-то может и аргумент 4) все зависит от конечного программиста, все мы разные) 5) тут все зависит от задач конечно получается эдакий холивар)
"Big Moms Hacker!" - Фраза. "Без применения грубой силы" - имеется в виду - "Схватить того кто захешировал и пытать пока не расскажет первоначальное значение". PS: А сайты 'md5 decoding' не тоже ли самое делают (хеш таблицы)? Я пробовал расшифровать с помощью нескольких хеш из твоего поста - ничего не вышло.
У меня возникло два вопроса, помогите, пожалуйста, разобраться: 1. Для того что-бы применять метод грубой силы или радужною таблицу, нам собственно нужна сама база с хеш паролями, которая где попало не валяется. В чем тогда смысл? 2. Хеш функция это же математический алгоритм, почему тогда не использовать приватный алгоритм (абсолютно новый или изменённый из уже существующий). Злоумышленник тогда имея на руках базу с хешами не сможет применить ни один из выше упомянутых видов атак, ведь у него не выйдет переводить варианты паролей без алгоритма.
Интересная тема. Но как я понимаю речь идет об утечке базы данных с хэшами паролей. Первое что приходит в голову - дополнительно шифровать хэш обратимым алгоритмом с ключом, и регулярно обновлять ключ, возможно в фоне постоянно проходиться по всем хэшам, расшифровывать их и снова шифровать с новым ключом.
"Нельзя получить обратного значения" при недопустимости коллизий говорит о том что есть взаимно однозначное соответствие и вероятно если размер хэша больше размера сообщения (в значащих битах как минимум) то при достаточно большой вычислительной мощности и/или достаточном времени вычислений сообщение можно таки восстановить. Тут как я понимаю в криптографии есть принцип вычислительной сложности - прямое вычисление за считанные мгновения, обратное за сотни-тысячи-миллиарды лет работы суперкомпьютера на момент использования хеш/крипто функции, т.е. то что когда-то его взломают даже не подлежит сомнению, для ранних алгоритмов с небольшой длинной ключа время подбора сейчас в домаших условиях занимает считанные часы, если не минуты. Ну и чуть не забыл про новых игроков на поле шифрования - квантовые компьютеры, которые всё и всех переиграют в ближайшее время) лайк поставил Закон Мура тоже надо принимать во внимание, на нем и основан тезис что вероятно скоро взломают, и даже можно с достаточной точностью оценить через сколько лет
Я правильно понимаю, что в принципе, если я на каком то сервисе введу нечаянно пароль от другого сервиса, то первый сервис его в любом случае видит в открытом виде и может записать себе куда-нибудь для каких-нибудь коварных целей?
Да, совершенно верно. Когда Вы регистрируетесь где либо и отправляете форму с емейлом и паролем, то его видно в чистом виде на сервере, соответственно, можно сделать просто зловредный сервис, который коллекционирует пароли. Лучше всего использовать авторизацию через провайдеры типа google, facebook и так далее, ну и опасаться тех мест, где такой авторизации нет
Чтобы скорость перебора была 100 миллиардов вариантов на алгоритме sha256, нужна ферма из 14 видеокарт RTX3080, работающих параллельно без последовательного SLI, скорость одной карты будет 7 гигахеш. На алгоритме MD5 скорость RTX3080 будет 52 гигахеш. Если поднять память будет ещё больше. У кого-то фермы из 100 карт RTX3080 разматают MD5 легко. И ещё, это рассматривается вариант от самого начала и до самого конца простого прогона всех вариантов, но есть фактор удачи - может повести разгадать в самом начале. Тогда результат может занять не 400 дней, а 20 дней допустим
Например, если злоумышленник знает один пароль (свой) в БД, то он легко найдет статическую соль. Если соль динамическая, то она как правило является частью хэша и тогда при нахождении коллизии легко понять какая часть строки является паролем.
Я конечно могу ошибаться или я не так понял из Вашей фразы "если у вас паролей 100000 то это займет кучу времени"(как я понял прогон делать для каждого хэша отдельно)... но если есть 100 000 хэшированных паролей(в базе так сказать), то что мешает во время прогона сразу проверять хэш в базе и получается за один прогон(если все пароли 8 символов N = 72^8), мы найдем все результаты...поправьте если я не прав,спасибо!
Ошибка в том, что вы считаете, что поиск по базе 100 000 значений - будет таким же быстрым, как одно сравнение. А это даже близко не так. В итоге вы будете почти мгновенно генерировать хэш, а потом долго ждать когда пройдет проверка по базе. И это мало того что медленно, так еще и последовательно, что в итоге не быстрее чем перебирать хэш на домашнем ПК - займет годы.
@@S0ERDEVS давно уже придумана концепция индексирования и поиск по индексу. Вам то этого и не знать. Так что слово «последовательно» в вашем ответе не применимо
Пользуйтесь российской криптографией. Там для одних и тех же данных у разных разработчиков СКЗИ хэш по ГОСТ Р 34.11-2012 (стандарт, ёпта!) вычисляется разный. Пробовал утилиты от CryptoPro, СКАД "Сигнатура", Verba-OW, МоКОД.
Все слова из "show must go on" попадают в 200 самых чато используемых слов английского языка. Если взять эти 200 слов и перебрать все комбинации по 4 слова получается 100 000 000 подходящих по длине фразы. Так что полный перебор был бы реален, если бы не знаки препинания, спецсимволы.
Да, но идея была в том, что поплуярных фраз на английском языке еще меньше. Но видимо я херово объяснил идею эксперимента, потому что только несколько человек написали имено фразы, и именно нужной длины. ) Остальные пишут произвольные наборы слов на английском языке. )
Нет, пароль надо делать символов 16. А про атаку дней рождений я маленько наколбасил. Там идея в том, что вероятность наличия коллизии выше их отсутствия уже на половине выборке от полной длины хэша.
Немного не понял.... если у меня есть хэши 100.000 паролей и я хочу узнать пароли, то мне не надо запускать брудфорс для каждого, я же просто могу после каждого расчета искать в БД хэшей получившейся результат. И получается брудфорс надо пройти только 1 раз а не 100.000. .... Само собой БД паролей надо отсортировать по хэшам..
Зависит от скорости поиска по БД, если сможет искать с такой же скоростью как сравнение по одному параметру, тогда на это уйдет столько же времени, сколько на поиск одного пароля. Я подробно разбирал эту ошибку для патронов. Надо считать не итерации, а время выполнения. Но искать по БД быстро вы не сможете. Поэтому это бессмысленно, не факт что будет быстрее чем последовательный перебор.
@@S0ERDEVS Да, конечно согласен, что весь вопрос в скорости поиска в массиве из 100тыс. хэшей.... Но мне кажется, что если система считает по 100 млрд хэшей в секунду, то и метод половинного деления сможет быстро осуществить... но, я конечно не претендую на истинность, т.к. не в теме.
Так скорость достигается за счет того, что каждое ядро работает отдельно и независимо от других ядер. Теперь представь, что мы посчитали хэш на одном ядре и нам его надо найти в БД, если мы будем делать поиск на том же ядре и только на нем, то это будет медленно, а если мы задействуем другие ядра для поиска, то они уже не будут считать хэши, что тоже резко просадит производительность. Плюс мы исходим из того, что такая скорость расчета хэшей достигается при расчете полного хэша, а это тоже не факт, возможно там так же используются оптимизации, которые отбрасывают частично расчитанные хэши, при несовпадении. В общем, я сильно сомневаюсь, что сравнение по БД будет в районе 2 порядков от 100 млрд.
@@S0ERDEVS Ну, да, наверное это тонкости оптимизации. Просто у меня немного не укладывается в голове, почему если для расчета 1-го хэша , к примеру, нужно 1 тыс. операций процессора и, допустим, к этой тысяче добавить ещё 16 (поиск половинным делением в массиве 100000... забудем про БД, поместим в КЭШ процессора или в ОЗУ, если в кэш не помещается), то это хоть как-то замедлит процесс.
Потому что расчет хэша не лезет в память, поэтому может очень эффективно считаться параллельно. Операции с памятью добавляют свои задержки (latency). Пока контроллер предоставит данные процессору для обработки проходит время, это очень критично в данной задаче. При обработке множества параллельных потоков обращение к одной и той же ячейки памяти вызывает вынужденный простой конкурирующих потоков. Повторяю, чтобы Ваше предположение было верно нужно добиться очень высокой скорости работы на одном ядре, без доступ к памяти, без парралельных вычислений. На одном "голом" ядре. Я не знаю способа сделать быстрым поиск по массиву при таком ограничении.
Чтобы иметь пароли, состоящие минимум из 8 случайных символов, нужно иметь очень хорошую память, либо иметь всего несколько таких паролей, которые будут повторяться для всего. Но это небезопасно. Держать физический блокнот или текстовый документ на компе тоже небезопасно. Поэтому относительно простые пароли никуда не денутся. Просто будут усложняться парой цифр и восклицательным знаком.
Ошибочка, если у вас 1ккк хэшей с паролями, то подбор всех их займет столько же времени как и 1го самого длинного, потому-что никто не мешает сравнивать свеже сгенерированный хэш со всеми из бд
"oh no, senpai"
В рамках эксперимента, предложенного в видео, нужно написать фразу на английском языке состояющую ровно из 16 символов (включая знаки препинания). Давайте посмотрим сколько фраз, подходящих под это условие, сходу придет на ум.
1:21 что такое Хэш
3:43 коллизии
4:38 классификация Хэш функций
6:10 парадокс дней рождений
8:30 функции формирования ключа
9:13 как борются с коллизиями
9:46 брутфорс
15:21 хэш таблицы
17:11 радужные таблицы
21:46: выводы
PoBHo16CuMBoJIoB
Посмотрим сколько нас ну да
Всегда восхищают люди с чистой речью и ясными мыслями.
я помню как хороший товарищ-реверсер всего парой фраз объяснил максимально просто почему в любом хеше есть коллизия: "просто потому, что хеширование - отображение бесконечного множества конечным" :)
а мне даже не нужно было это объяснять. это же и так очевидно
@@404Negative ути пути, а у меня папа мент и чо ты мне сделаешь?
Все абсолютно верно, только для современных хэш-функций начиная c SHA256 общее количество возможных хешей настолько огромное, что до сих пор неизвестна ни одна коллизия - чтобы две разные строки давали одинаковый хэш и потом и считается что данным феноменом можно пренебречь, а так ты конечно же абсолютно прав. Если произвольной длины информация сжимается всего в 32 байта то разумеется дубли обязаны быть
Крипто хэш не обратим, и устойчив к любым атакам (почти) :-). А если пароль выше 16 символов, устойчив к любым атакам.
@@romankrylov3504 кроме расчёта на квантовом компьютере
Я в восторге при просмотре ваших роликов. Всегда получаю дополнительную информацию не связанную с роликом. Легко и доступно спасибо.
"К сожалению техника не стоит на месте..." ахаха))) Есть о чем сожалеть...
"Hello world!" )
Должно быть 16 символов )
Hello Big World!
@@S0ERDEVS так 16 15+ пробел и скобочка
@@S0ERDEVS я всё равно плюсанул, ибо лень считать..
f[f[f[f[f[f[f[f[f[f[f[[f[f[f[f
Как просто о сложном... Спасибо.
6:21
Какой же однако удачный пример😆
У меня в классе 24 человека, и у меня др в один и тот же день с моим одноклассником)
"BoyNextDoor"
ахах) 20 человек в теме
@@victorburuyan1691 just lube it up
♂ That's amazing ♂
спасибо за видео, первая часть была очень информативна и полезна
с радужными таблицами, ничего не понял, буду сам разбираться :3
топовый блогер, очень круто и доступно рассказывает, успехов каналу
Знаю, что видео старое, просто хотел поглумиться над сбербанком, у которого недавно выяснилось, что они хранят пароли пользователей в открытом виде, мотивируя это тем, что это для того, чтоб пароли были регистронезависимыми, чтоб пользователям было удобно. фэйс палм.
Замечательно и круто! Палец вверх! 👍
Большое спасибо за видео! Как всегда очень интересно
немного в тему применения соли для простых пользователей.
чтобы не записывать и не сохранять пароли в браузерах я как параноик использую следующий способ.
Придумываем парольную фразу. которую легко запомнить. и которую можно даже записать. придумываем ее по принципу {прилагательное} {существительное} {глагол}
например "быстрый конь бежит". далее берем по 3 первых символа от каждого слова (бысконбеж) и вводим русскими буквами в английской раскладки получается ",scrjy,t;"
добавляем статическую соль например виде (){} или знаков препинания, цифр. "{,scrjy,t;}","*,scrjy,t;*","321,scrjy,t123". далее добавляем динамическую соль формируя ее в зависимости от домена сайта например беря первую и последнюю букву домена. например для yandex.ru => yx для vk.com => vk. это нужно чтобы на различных сайтах пароли были различными. так для yandex.ru пароль будет "y{,scrjy,t;}x", для vk.com => "v{,scrjy,t;}k", для somedomen => "s{,scrjy,t;}n"
Идея хорошая, но недоработанная.
Все пароли имеют 1 шаблон, различаются первым и последним символом... Ну, так себе паранойя. Здесь вся хитрость в алгоритме, а если утянуть один пароль, то при знании алгоритма построения пароля, все другие компроментируются автоматом.
А мы знаем, что одна из основ безопасности - в секрете хранится должен пароль, а алгоритм может быть публичным.
Гораздо лучше такая связка:
Имеется секретное слово (мастер-пароль), который используется лишь для генерации всех паролей. От связки (мастер_пароль + название_сайта) берется хеш, и пропускается через base64. И там уже берется подстрока нужной длины (10, 12, 16...) символов.
Например:
Секретное слово "Pa$$w0rd" :) Сайты те же, yandex.ru и vk.com
На сайте approsto.com/sha-generator/ забиваем Pa$$w0rd yandex.ru
для SHA512 base64 hash получается строка "ZC5webUTKgAJzEpHULS2hfF5mkP20Ud........."
А для Pa$$w0rd vk.com получается строка "niUZs2imqS1lV7xGULULVRA3Z7tsiX/eHz........."
Так же намного лучше, никаких общих подстрок между паролями.
Менять их "оптом" тоже несложно:
К связке мастер_пароль + название_сайта добавляется дата изменения, например "Pa$$w0rd 16.10.2019 yandex.ru"
Причем строку "16.10.2019 yandex.ru" можно хоть на рабочем столе в txt хранить, хоть в облаке - без мастер пароля от нее мало пользы. Через месяц надо сменить пароль - поменял строку на "Pa$$w0rd 16.11.2019 yandex.ru", получил АБСОЛЮТНО новый пароль, который не нужно запоминать. ))
Единственное, для бОльшей секьюрности можно не пользоваться approsto.com/sha-generator/ и прочими онлайн сервисами, а использовать доверенное приложение для PC/телефона (такие вообще есть??) или написать самостоятельно ))
Как-то так.
FF неплохо шифрует пароли и если вы забудете свой пароль, которым зашифровали базу, то вы никогда её не расшифруйте, а лучший пароль - это тот, который ничего не значит, ни с чем не ассоциируется и не имеет никакого смысла.
Просто один раз сгенерируйте себе такой мастер-пароль, заучите его наизусть и забудьте про все сложности и паранойю.
@@MAGNet1911 ага доверять какой либо программе. может плагины еше в торе включить и мобильным начать пользоваться.
@@mytolga88 я прикидываю если этот сайт поменяет алгоритм :) втихаря
ответ: show_must_Go-On!
Это-же не крипто хэш, крипто хэши не обратимы, только если найти коллизии на каждый символ, что на лету почти не возможно.
что касается алгоритма поиска коллизий, то такие инструменты пишут обычно сами.
Брут Форс сейчас не в моде, обычно хорошо работает обход, а не взлом.
show_must_Go-On!
Действительно !
Самый нормальный iTшник на ютюбе. Не водолей как некоторые
Больше всего мне понравилось в этом видео, что я не узнал ничего нового.
Значит у меня не все так плохо, спасибо книгам Таненбаума!
А так, видео реально полезное.
А что если в базе хранить три хеша от разных алгоритмов(даже не самых сложных) и давать доступ только если a&&b&&c?
12:19 можно просто нагенерить бесконечное количество пароль используя один и тот же алгоритм и возможно какие-то из этих комбинаций смогут пригодится еще где-то =)
Спасибо, нужно будет воспользоваться.
Спасибо! Очень классная тематика! Отлично!
а для получения нужного пароля за счет вычисления хеша надо ж еще и знать какая функция используется, это тож путем перебора делают?
Мне как-то один джавист лайфхак подсказал для формирования своих паролей. Использовать слова из старорусского на латиннице, которые уже не используются, или из других очень редких для it языков, вроде татарского или чукотского. Плюс его писать с большой буквы, дальше полую дату своего рождения в 16ричной системе (лучше ее запомнить как константу), и в конце поставить точку
Полезный контент! Отлично
Расскажите про инкапсуляцию, говорят это сокрытие данных
Инкапсуляция это помещение одних данных внутрь других. Только и всего. Используется повсеместно в разных целях.
@@antonm.885 если что это был троллинг с этого видео ua-cam.com/video/BHNt1fcg8iw/v-deo.html
Месье знает толк
И да, спасибо за ролик, очень интересно.
пример динамической соли где бы посмотреть? ктонибудь может подскажет
понял.. вот в чем дело The term "dynamic salt" is not that it is changing every time you verify it. It only means that it is dynamic for each record.
было дело, подогревал интерес к технологиям, изучая хацкерские инструменты. и вот что сказать накопилось) самый лучший способ хеширования - неизвестный хакеру, недоступный в hashcat, john the ripper и аналогах, сложный и долгий для просчета. bcrypt хорош - но прожорлив. sha512 неплох, но считается в разы быстрее. мне нравится PBKDF2-HMAC-SHA256/512. среднячок в соотношении расход ресурсов к времени брутфорса.
если исходный код хеширования пароля недоступен хакеру - 2-3 простейших действия сведут любой брутфорс на нет. удалите 3-й и 12-й символ, поменяйте какие то символы местами. используйте дополнительно статичную соль. в итоге - в бд нет соли, у хакера нет полного алгоритма, да и софт для брутфорса говорит, что таких хешей он не знает.
насчет недоступности мощностей - это вы зря. всегда есть возможность заказать брут хеша в интернетах. причем с оплатой за решенный хеш.
вообще в бруте паролей с sql дампов цели 2 - компрометация паролей обычных юзеров, в надежде, что они используют тот же пароль в указанной почте. и никто не станет считать 72^9 паролей для каждого юзера. тут обычно по словарю подбор ведут. либо компрометация пароля админа, модератора etc.(тут можно и брут юзать) но эта проблема неплохо решается сокрытием страницы входа. ограничением входа по ip, useragent, 2-х факторке.
есть вот случай. blind and time based sql inj. полный дамп username:password. включая пароль админа. брут md5(md5($pass)) для админа занял на 1060TI 4 дня. Night1988)) и чтобы вы думали? за месяц брутфорса не нашел админ панель))
да это тема PBKDF2-HMAC-SHA256/512
Только вот что я не пойму - в большинстве случаев-то у взломщика нет доступа к хешу т.к. он храниться где-то в базе данных, которую он собирается взломать. Ткчт эти способы взлома в большинстве случаев не помогут или я чего-то не понимаю?
Если ты алеша, а не сисадмин, то к серверу БД можно подсосаться без пароля и получить всю инфу за запрос схемы :/
Базы данных очень часто сливают
Спасибо, очень познавательно, подписка)))
Есть желание переехать в Москву или СПб, не скучно у себя в городе?
Привет!
На тебе окуляры с "технологией" Blue Block?
Расскажи что-то о них: где покупал? за сколько? стоит ли использовать в работе? глаза меньше устают? когда надеваешь? можно ли использовать в быту (например, во время вождения автомобиля)?
у него уже было видео про эти очки, точно название не помню, но думаю поиском по каналу по слову "очки" найдется.
Суть таких очков в цветофильтре голубого, которого с избытком излучают светодиоды с холодным светом, тем самым снижается напряжение на сетчатку от подсветки монитора.
Ну и по личным ощущениям, я стал лучше различать оттенки с монитора, после того как одел очки с таким фильтром, хотя возможно это особенности моего остигматизма, ибо менять очки я пошел, когда понадобились другие диоптрии.
@@ДмитрийБеляев-ъ1з Спасибо!
Спасибо, интересно!
Вместо динамической + статической соли можно просто динамическую взять чуть подлиннее, не?
Я даже в начале видео могу сказать что там "Hello world!"😁
Оч крутой ролик, сразу захотелось о чем-то таком почитать и попробовать руками))
не совсем понял, зачем к динамической соли добавлять ещё и статическую
"i'm so happy now"
"Сервер будет греть воздух для расчёта паролей." ©Soer
Он сутками видео снимает ради нас, дня два прошло точно, по свету видно, спасибо! Пойду взламывать акк в майнкрафте.
Ох нет только не md5. Однажды я забыл пароль от админки сайта и с помощью базы данных к которой имел доступ вытащил пароль в md5 формате, через прогу которая подбирает md5 хэш, работала (вычисления делала) она кстати на gpu, так как там вычисления были быстрее. Итог, за 2 минуты подобрал свой пароль)
Archangel но если база доступна была не только на чтение, то можно было бы вставить хеш от 123456 и войти, а потом сменить пароль :D (ну или просто сменить на хеш нового)
@@ГошаАввакумов-к1т Сам так делал. Как-никак админ всё же и доступ к базе имелся. Но прокатывает не всегда, но не в этом случае. Хорошо когда знаешь как получаются хэши движком. Видел самописный движок с двойным прогоном пароля по функциям.
Why I should use hash?
Соер, ты случайно на C не пишешь? Ты говорил делаешь свою систему мониторинга, интересно про это послушать
c уже мертв
@@unknown-vq1gj конечно конечно) с чего ему быть мертвым?)
@@igornatale
C:
1) отсутсвует ооп;
2) нигде не используется;
3) старый;
4) сложный;
5) безполезен в эпоху пайтхона и высокоуровневых языков програмирования;
@@unknown-vq1gjа драйвера разве не на с пишут?
C как я помню функциональный.
И ООП и функциональный имеют свою плюсы и минусы
2) драйвера вроде как на с пишутся
3) для кого-то может и аргумент
4) все зависит от конечного программиста, все мы разные)
5) тут все зависит от задач конечно
получается эдакий холивар)
@@igornatale драйвера пишут на VHDL (Hardware Descriptive Language) и Verilog.
На сколько устойчив пароль из 512 символов ?
"Big Moms Hacker!" - Фраза.
"Без применения грубой силы" - имеется в виду - "Схватить того кто захешировал и пытать пока не расскажет первоначальное значение".
PS: А сайты 'md5 decoding' не тоже ли самое делают (хеш таблицы)? Я пробовал расшифровать с помощью нескольких хеш из твоего поста - ничего не вышло.
У меня возникло два вопроса, помогите, пожалуйста, разобраться:
1. Для того что-бы применять метод грубой силы или радужною таблицу, нам собственно нужна сама база с хеш паролями, которая где попало не валяется. В чем тогда смысл?
2. Хеш функция это же математический алгоритм, почему тогда не использовать приватный алгоритм (абсолютно новый или изменённый из уже существующий). Злоумышленник тогда имея на руках базу с хешами не сможет применить ни один из выше упомянутых видов атак, ведь у него не выйдет переводить варианты паролей без алгоритма.
Интересная тема. Но как я понимаю речь идет об утечке базы данных с хэшами паролей. Первое что приходит в голову - дополнительно шифровать хэш обратимым алгоритмом с ключом, и регулярно обновлять ключ, возможно в фоне постоянно проходиться по всем хэшам, расшифровывать их и снова шифровать с новым ключом.
лучше солить.
Привет, хорошее видео, а можешь делать больше видео непосредственно с кодом ( с#, js). Думаю это было бы очень полезно.
"Нельзя получить обратного значения" при недопустимости коллизий говорит о том что есть взаимно однозначное соответствие и вероятно если размер хэша больше размера сообщения (в значащих битах как минимум) то при достаточно большой вычислительной мощности и/или достаточном времени вычислений сообщение можно таки восстановить. Тут как я понимаю в криптографии есть принцип вычислительной сложности - прямое вычисление за считанные мгновения, обратное за сотни-тысячи-миллиарды лет работы суперкомпьютера на момент использования хеш/крипто функции, т.е. то что когда-то его взломают даже не подлежит сомнению, для ранних алгоритмов с небольшой длинной ключа время подбора сейчас в домаших условиях занимает считанные часы, если не минуты. Ну и чуть не забыл про новых игроков на поле шифрования - квантовые компьютеры, которые всё и всех переиграют в ближайшее время) лайк поставил
Закон Мура тоже надо принимать во внимание, на нем и основан тезис что вероятно скоро взломают, и даже можно с достаточной точностью оценить через сколько лет
вот только есть один маленький нюанс. квантовых компьютеров не существует. и никогда не будут существовать. это математическая гипотетическая модель
@@404Negative так что там с "квантовых .. не существует"?)
@@misc2850 не существует
классный материал
социальная инженерия - наше всё)
Как посчитать вес радужной таблицы ?
На счетных палочках.
Кто нибудь может дать ответ нормальный ?
Vielen Dank aus Deutschland!!
Я правильно понимаю, что в принципе, если я на каком то сервисе введу нечаянно пароль от другого сервиса, то первый сервис его в любом случае видит в открытом виде и может записать себе куда-нибудь для каких-нибудь коварных целей?
Да, совершенно верно. Когда Вы регистрируетесь где либо и отправляете форму с емейлом и паролем, то его видно в чистом виде на сервере, соответственно, можно сделать просто зловредный сервис, который коллекционирует пароли. Лучше всего использовать авторизацию через провайдеры типа google, facebook и так далее, ну и опасаться тех мест, где такой авторизации нет
@@ibondar-ua эээээ
Чтобы скорость перебора была 100 миллиардов вариантов на алгоритме sha256, нужна ферма из 14 видеокарт RTX3080, работающих параллельно без последовательного SLI, скорость одной карты будет 7 гигахеш. На алгоритме MD5 скорость RTX3080 будет 52 гигахеш. Если поднять память будет ещё больше. У кого-то фермы из 100 карт RTX3080 разматают MD5 легко. И ещё, это рассматривается вариант от самого начала и до самого конца простого прогона всех вариантов, но есть фактор удачи - может повести разгадать в самом начале. Тогда результат может занять не 400 дней, а 20 дней допустим
А если использовать соль, как тогда злоумышленник сможет угадать пароль по хэшу?
Например, если злоумышленник знает один пароль (свой) в БД, то он легко найдет статическую соль. Если соль динамическая, то она как правило является частью хэша и тогда при нахождении коллизии легко понять какая часть строки является паролем.
"Resonance between battlefields"
Best channel ever!
Я конечно могу ошибаться или я не так понял из Вашей фразы "если у вас паролей 100000 то это займет кучу времени"(как я понял прогон делать для каждого хэша отдельно)... но если есть 100 000 хэшированных паролей(в базе так сказать), то что мешает во время прогона сразу проверять хэш в базе и получается за один прогон(если все пароли 8 символов N = 72^8), мы найдем все результаты...поправьте если я не прав,спасибо!
Ошибка в том, что вы считаете, что поиск по базе 100 000 значений - будет таким же быстрым, как одно сравнение. А это даже близко не так. В итоге вы будете почти мгновенно генерировать хэш, а потом долго ждать когда пройдет проверка по базе. И это мало того что медленно, так еще и последовательно, что в итоге не быстрее чем перебирать хэш на домашнем ПК - займет годы.
@@S0ERDEVS давно уже придумана концепция индексирования и поиск по индексу. Вам то этого и не знать. Так что слово «последовательно» в вашем ответе не применимо
спасибо
Годнота
Слово из 16 символов: programming
"Why so serious?©"
Пользуйтесь российской криптографией. Там для одних и тех же данных у разных разработчиков СКЗИ хэш по ГОСТ Р 34.11-2012 (стандарт, ёпта!) вычисляется разный. Пробовал утилиты от CryptoPro, СКАД "Сигнатура", Verba-OW, МоКОД.
Free_your_mind_!
Спасибо за интересный видос. На мой взгляд не хватает иллюстраций
No problem, bro!
Все слова из "show must go on" попадают в 200 самых чато используемых слов английского языка. Если взять эти 200 слов и перебрать все комбинации по 4 слова получается 100 000 000 подходящих по длине фразы. Так что полный перебор был бы реален, если бы не знаки препинания, спецсимволы.
Да, но идея была в том, что поплуярных фраз на английском языке еще меньше. Но видимо я херово объяснил идею эксперимента, потому что только несколько человек написали имено фразы, и именно нужной длины. ) Остальные пишут произвольные наборы слов на английском языке. )
С такой объяснялкой нужно преподом быть
watchItTwice!!!, так что пароль надо делать
Нет, пароль надо делать символов 16. А про атаку дней рождений я маленько наколбасил. Там идея в том, что вероятность наличия коллизии выше их отсутствия уже на половине выборке от полной длины хэша.
Что-то понял , что-то нет, но было затягивающее)
Немного не понял.... если у меня есть хэши 100.000 паролей и я хочу узнать пароли, то мне не надо запускать брудфорс для каждого, я же просто могу после каждого расчета искать в БД хэшей получившейся результат. И получается брудфорс надо пройти только 1 раз а не 100.000. .... Само собой БД паролей надо отсортировать по хэшам..
Зависит от скорости поиска по БД, если сможет искать с такой же скоростью как сравнение по одному параметру, тогда на это уйдет столько же времени, сколько на поиск одного пароля. Я подробно разбирал эту ошибку для патронов. Надо считать не итерации, а время выполнения.
Но искать по БД быстро вы не сможете. Поэтому это бессмысленно, не факт что будет быстрее чем последовательный перебор.
@@S0ERDEVS Да, конечно согласен, что весь вопрос в скорости поиска в массиве из 100тыс. хэшей.... Но мне кажется, что если система считает по 100 млрд хэшей в секунду, то и метод половинного деления сможет быстро осуществить... но, я конечно не претендую на истинность, т.к. не в теме.
Так скорость достигается за счет того, что каждое ядро работает отдельно и независимо от других ядер. Теперь представь, что мы посчитали хэш на одном ядре и нам его надо найти в БД, если мы будем делать поиск на том же ядре и только на нем, то это будет медленно, а если мы задействуем другие ядра для поиска, то они уже не будут считать хэши, что тоже резко просадит производительность.
Плюс мы исходим из того, что такая скорость расчета хэшей достигается при расчете полного хэша, а это тоже не факт, возможно там так же используются оптимизации, которые отбрасывают частично расчитанные хэши, при несовпадении.
В общем, я сильно сомневаюсь, что сравнение по БД будет в районе 2 порядков от 100 млрд.
@@S0ERDEVS Ну, да, наверное это тонкости оптимизации. Просто у меня немного не укладывается в голове, почему если для расчета 1-го хэша , к примеру, нужно 1 тыс. операций процессора и, допустим, к этой тысяче добавить ещё 16 (поиск половинным делением в массиве 100000... забудем про БД, поместим в КЭШ процессора или в ОЗУ, если в кэш не помещается), то это хоть как-то замедлит процесс.
Потому что расчет хэша не лезет в память, поэтому может очень эффективно считаться параллельно. Операции с памятью добавляют свои задержки (latency). Пока контроллер предоставит данные процессору для обработки проходит время, это очень критично в данной задаче. При обработке множества параллельных потоков обращение к одной и той же ячейки памяти вызывает вынужденный простой конкурирующих потоков.
Повторяю, чтобы Ваше предположение было верно нужно добиться очень высокой скорости работы на одном ядре, без доступ к памяти, без парралельных вычислений. На одном "голом" ядре. Я не знаю способа сделать быстрым поиск по массиву при таком ограничении.
Я подписался!
Рассказал как хэшировать пароли, и не показал как это делать хотя бы примерно. Информативность видео - over 1000%
Пароль преобразуете в 1024-битное двоичное число. Для сложности можно считать CRC1024 или другую псевдослучайную функцию.
Соер, что Вы скажите о github.com/BohdanTheBest20/DataSecurityPHP ?
Your_Bunny_Wrote
Чтобы иметь пароли, состоящие минимум из 8 случайных символов, нужно иметь очень хорошую память, либо иметь всего несколько таких паролей, которые будут повторяться для всего. Но это небезопасно.
Держать физический блокнот или текстовый документ на компе тоже небезопасно.
Поэтому относительно простые пароли никуда не денутся. Просто будут усложняться парой цифр и восклицательным знаком.
cout
Мечь алмазный на заднем плане:)
That is why you!
Все хорошо, но к чему эта виньетка?
Быть или не быть фраза?)
Давно я не чувствовал себя тупым )
"Sixteen_symbols*"
Идеальным вариантом будет
sha512 - argon2 - aes-256-gcm
Видео не плохое но очень поверхностное
I wish you best.
"That's happened!"
Ошибочка, если у вас 1ккк хэшей с паролями, то подбор всех их займет столько же времени как и 1го самого длинного, потому-что никто не мешает сравнивать свеже сгенерированный хэш со всеми из бд
По твоему сравнение не является операцией, занимающей время?
Hack the Planet!
"can you hash password?"
В твоих очках я вижу монитор, в нём человек, который смотрит на меня Оо. Под таким паролем я сохраню этот ролик.
"Hello, mom!! )"
Фраза: "I killed my wife"
hello, crypto!!!!
Снова бессоные ночи.
"bambaleylo.easy!"
Hello,_my_World!
Hi,_my_friends_!