Здорово. И очень понятно. Сегодня писал авторизацию и использовал bcrypt. Но не мог понять из доков да и так, что такое хэширование. Написал как-то, а сейчас в 4 часа ночи посмотрел видео, и все верхнеуровнего стало понятно :) Спасибо :)
5:54 утверждение "придется перебирать все возможные значения соли" -- неверно. обычно, соль хранится вместе с паролем, и она известна. смысл соли в том, чтобы избежать именно атаки по радужным(отимизированным для поиска хеш => исходная строка) таблицам, т.е. hash(x) = y1, а hash(x + C) = y2, при этом y1 и y2 различаются кардинально (в силу того самого пресловутого лавинного эффекта). допустим, построить таблицу без соли легко для всех возможных значений x, но тогда придется построить словарь для каждого значения соли, что уже довольно затруднительно. но перебирать ее не нужно, принципиально, иначе бы пользователь при вводе пароля должен был бы помнить эти же самые рандомные значения символов, которые добавляются к его паролю :)
Разумный текст. Подскажи как на практике работают с солью. В ролике она показана динамическая (разная для разных юзеров). Как тогда на сервере ее воспроизводят для нужного пользователя? За что зацепиться серверу ( ведь логин пользователя в открытом виде не передают). Или ее тупо генерят на клиенте и отдельным параметром передают на сервер в каждом запросе авторизации. А логин и пароль превращают в хэш и передают только его.
@@mdyrhino как я и сказал, на практике чаще всего ее просто хранят вместе с хешем пароля. и да, для каждого пароля она своя -- генерится автоматически, когда хешируется пароль (иначе можно построить предподготовленные таблицы с конкретной солью, но об этом позже). если раньше (лет 10 назад) надо было париться над тем, куда и как ее вставлять, сейчас все делают библиотеки. пример довольно стандартного представления "хеша" пароля: `$5$rounds=5000$usesomesillystri$KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6` (взято из документации crypt в пхп), здесь долларами разделяется: 1. $5 -- код алгоритма хеширования (в данном случае, sha256), 2. $rounds=5000 -- параметры конкретно для данного алгоритма хеширования. в данном случае, rounds=5000 означает, что sha256() был применен 5000 раз. 3. $usesomesillystri -- та самая соль 4. $KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6 -- сам хеш пароля как работает функция проверки пароля (скажем, password_verify в пхп или другие аналогичные): на вход поступает сам пароль, который ввел пользователь +вот эта вот строка, которую я показал выше. внутри функции мы определяем, что код 5 -- значит надо делать sha256, по параметрам смотрим, что надо это делать 5000 раз, соль такая-то, ну и значит нам надо сделать что-то вроде ``` $salt = 'usesomesillystri'; $hash = $password . $salt; for ($i = 0; $i < 5000; $i++) { $hash = sha256($hash); } if ('KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6' === $hash') { return true; // для наглядности } else { return false; } ``` к чему я это: да к тому, что соль почти всегда хранится вместе с паролем, и если утек куда-то хеш, то значит, с вероятностью (99.9%) утекла и соль. Надо сделать исключение на случай всяких людей с ФГМ, которые придумывают "свое шифрование", хранят соль отдельно, скажем, в файлике. потом, при переносе на другой сервер базу перенесли, а вот про файлик этот забыли, и кирдык, больше ни одного пароля на валидность проверить стало нельзя. На самом деле в этом и нет никакого смысла, еще раз: соль нужна только для того чтобы не было атаки по предподготовленным таблицам (коих уже миллионы в сети). т.к. выход функции ограничен N-битами (скажем, md5() -- 128 бит, sha1() -- 160, sha256() -- 256 итд), первое, что приходит в голову всем, кто знаком с крипто-хешами, наверное, первое что приходит в голову -- взять и подбирать все возможные строки, делать, скажем, `md5($input)` и складывать все это дело в файлик. и вообще можно полностью покрыть все эти 128 бит (на самом деле, ПОЧТИ все), скажем, используя не один, а сотни компьютеров, или даже спец устройств (скажем, fpga). но просто так в файлик все не сложишь, даже в случае 128ми битного хеша, как md5 (т.е. нам понадобится хранить 2^128 значений -- таких жестких дисков еще не придумали, и даже все компы мира не смогут хранить такое количество информации, по крайней мере в 2021ом году). Поэтому был придуман алгоритм хрананения таких таблиц, и назвали его "радужным" (не помню уже, почему именно "радужный", но не суть, так назвали) -- и в итоге говорят, "чтобы не было атаки по радужным таблицам", имея ввиду на самом деле именно любые преподготовленные таблицы :) В общем, суть в том, что если пароль не солится, то его можно просто найти в таких таблицах (которые годами генерятся на куче компов), и получить строку, хеш от которой равен тому, что вы указали. Но если изначально пароль "посолить", то вы получите совершенно другую строку (вот нельзя прям взять и перебрать все возможные строки на входе -- их бесконечность. добавление соли делает строку, скажем, на 16 байт длиннее, а даже перебрать все возможные варианты из 16ти байт вроде как нельзя, иначе бы AES128 был бы такой себе алгоритм :)), и даже если была бы теоретическая возможность получить 100% покрытие всех хешей -- это не поможет, вы просто получите ДРУГУЮ строку, у которой хеш равен тому, что вы указали (т.е. в случае соленых паролей вам могло бы показаться, что вы получите изначальный вид password + salt, но нет, скорее всего это будет просто совершенно другая строка, просто хеш у нее совпал. и проверку на password_verify она не пройдет. хотя, конечно, может вам дико повезет, но нет, вероятность такого события считается мизерной, проще купить лотерейный билетик и выйграть джекпот:) ). Вот для этого пароль солится. сама по себе соль -- это открытая информация, никто ее сильнее чем сам хеш, как правило не скрывает, ибо в этом нет смысла.
@@mdyrhino по поводу остального, как правило, в хеш превращается только сам пароль, поскольку это и есть тот самый "секрет", который знает только сам пользователь. вообще, по идее, можно было бы хранить и сам пароль как таковой, и вообще не париться над хешем. но просто люди часто используют один и тот же пароль на разных сайтах, и все это делается лишь для того, чтобы админ какого-то мелкого сервера не мог залогиниться, скажем, под вашей почтой:) (а поверьте, у админа есть доступ к хешам, да-да). и вот не имея понятия, что там за пароль, можно узнать, правильный ли пароль ввел пользователь. но нельзя узнать сам пароль. поэтому же, само собой, его можно изменить. но не узнать :) (хотя, на самом деле, вру, само собой можно при наличии доступа к коду на сервере, куда-то отдельно складывать то, что ввел пользователь, разумеется, но "честным" админам обычно это не нужно, а вот условному злоумышленнику, который каким-то образом получил доступ к базе -- да. да, конечно, плохо, что получили доступ к базе. но мы, программеры, не супермены, и иногда делаем ошибки. собственно, основное предназначение хеширования паролей -- это на случай, если что-то утечет, чтобы злоумышленник не мог получить исходный пароль у всех пользователей. ему точно так же придется перебирать кучу всяких разных вариантов, и поэтому тут оченнь важно, чтобы хотябы сам пароль был не словарный, и достаточно длинный -- тогда даже при наличии хеша его не узнают)
да, учитывайте, что видео на ютьюбе -- это в первую очередь, развлекательные, а не познавательные. к примеру, я не спорю, что "идеальная криптографическая хеш-функция" должна вычисляться быстро. (слайд "свойства идеальной криптофункции", 3:00). на практике же не придумали ничего иного, кроме как именно усложнять саму функцию, за счет чего перебор хешей становится тупо нерентабельным. всякие scrypt и bcrypt "гордятся" именно тем, что скорость вычисления их -- это порядка 33-50 хешей в секунду на средней видюхе (на той же самой видюхе md5 -- это 50e9 хешей в секунду), и как ни странно, на обычном проце скорость может быть даже выше. в общем, уходят от идеи "быстрого" вычисления. но именно "идеальная" -- да, должна вычисляться быстро. но пока никто в мире не знает, как это сделать :D отсутсвие коллизий -- это опять таки, теоретическая штука. коллизии есть всегда, поскольку исходных строк бесконечность, а выход -- это всегда ограниченное число бит. коллизии есть всегда. их нет только в теории. но т.к. видео якобы именно о теории, я с этим ни в коем случае и не спорю :)
лично для меня эта, казалось бы, мелкая и незначительная, но принципиально неверная фраза просто говорит о том, что автор (возожно, сценарист, или даже технический консультант) недостаточно разобрался в том, как работает крипто-хеширование. остальное, скорее всего, было взято из "Прикладной криптографии" Шнаера (а может и тупо с вики, не знаю), но в общем и целом более-менее грамотно, других прям явных косяков (именно с точки зрения технической части) не заметил. остаются, конечно, вопросы, скажем: откуда вам известно, какое хеширование используется в twitter или dropbox. у них в документации так написано? почему бы не указать было ссылку в конце видео? или вы сами ломали и twitter и dropbox, и точно знаете, что у них в первом параметре, после доллара, стоит 2y ? :D ну или автор успел поработать и там и там, получил и там и там админские доступы к паролям, и после этого снял это видео?:) конечно, понятно, что скорее всего, bcrypt, и наврядли сами разрабы будут это отрицать, но блин, почему отсылки именно к крупным вендорам? но это все -- косяки маркетинга, просто не упоминая названия крупных брендов, видимо, видео не раскрутишь, или я не знаю... ) с технической стороны в целом более-менее грамотно, для себя узнал, что ничего нового на ютьюбе не узнаю, по крайней мере в той сфере, в которой сам немного разбираюсь :D
Если у тебя фиксированная длина выходной строки, а входная не ограничена, то колизии непременно будут что бы ты не делал. Это следствие из требований входных параметров.
Вопрос: а соль, которая добавляется к хеш функции пароля, каждвй раз генерируется случайно? Если да, то как тогда сравнивать пароль при авторизации и изначально введенный пароль пользователя?
Для хеширования паролей используется "соль", но она же тоже где-то должна храниться, и заполучив хеши и связанные с ними "соли" можно так же само вычислить хеши для наиболее часто используемых паролей. Так же получается?
Тут в другом вопрос. В ролике показано применение разной соли для одинаковых строк пароля. Но как сгенерировать разную соль для разных пользователей, чтобы ее мало того чтобы запомнить и но каким то защищённым образом передать на сторону сервера, чтобы прошла авторизация Разных пользователей с одинаковым паролем но разно-сгенерированной солью. В ролике не рассказали про эти механизмы генерации разной соли и способы ее воспроизведения на проверяющей (серверной) стороне. Ее что в открытом виде в запросе вместе с хэшем передают? Или существует еще одна хэш функция, которая на стороне сервера однозначно генерирует ту же соль, например от имени пользователя. Кто пояснит как соль на практике реально работает?
Т.е. если хеш функция однонаправленная значит и то, что и сама администрация условного вк не сможет получить доступ к моей странице если у меня сложный пароль? Т.е. зайти на аккаунт и написать от моего имени кому-то сообщение, например
А что мешает получив хэш из украденой БД сервиса, осуществить авторизацию без пароля, чисто по хэшу? Ведь сервис сверяет полученный от пользователя хэш с хэшем в базе и по идее ничего не мешает обойти этап получения хэша из пароля и сразу отправить сервису хэш пароля получив доступ к аккаунту.
Как выглядит результат работы защиты дропбокса? Мы там прогоняем хэшсумму предыдущего алгоритма через последующий? алгоритм? Или плюсуем хэшсуммы исходного текста, который прогнали через hash, bcrypt, AES?
Так просто за соль сказал, как будто это тупо рандомная строка подмешивается к паролю. Сделал я однажды такое в приложении, потом по своему же паролю юзер не мог войти. Соль - это не просто
Я вот так и не понял, разве требование уникальности хэша не противоречит тому, что должно быть как можно меньше коллизий? Типо ведь чем больше коллизий, тем больше надо проверить, нет?
Извините, если я правильно понял, то шифрования недостаточно так-как можно вычислениями вывести изначальное данное. А хэш, это допустим просто рандомные цифры и буквы, которые не имеют связи с данными, а просто называют их?
Не совсем понял один момент. Как получатель программы понимает, что принятая им подпись в виде хеша является подписью именно автора программы, а не кого-либо ещё?
В том то и дело что хэш функция создает отпечаток информации, но не уникальный! Поскольку хэш функция отображает пространство большего числа аргументов на меньшее по числу вариантов пространство результатов за счет свертки. Именно свертка не дает однозначно узнать аргумент хэш функции при обратном преобразовании. Другими словами всегда существует несколько разных паролей имеющих одинаковый хэш ))) Рейнбоу тайблс это подтверждат!
Очень информативное видео!) Только не понятно, как блок в блокчейне хранит свою хэш сумму, если хэш сумма основана на информации, хранимой в блоке (получается включая саму хэш сумму), получается некий парадокс :-/
нет, не блок хранит свой хеш, а блок хранит хеш предыдущего блока, например: БЛОК 1: БЛОК 2: , БЛОК 3: , БЛОК 4: , И так далее. Хранение хеша в блоке, самого блока технически невозможно.
Я: Пытаюсь узнать пароль от своего давно утерянного аккаунта имея только адресс электронной почты и Хеш пароля. Видео каждые 2 минуты: можно взломать аккаунт вот так, но уже придумали как это полностью нейтрализовать.
Да могут. Только это не так просто сделать. Md5 уязвима к коллизиям, но найти эти коллизии достаточно сложно. Легче чем в других, современных хэш алгоритмах, но все равно сложно и требует времени.
В торрент файле уже есть защита в виде SHA1 хешей. Если другой пользователей тебе пересылает кривой кусок, твой торрент клиент его не примет. Для SHA1 хоть и возможно построить коллизию, но нужно иметь супер компьютер, что бы сделать это. Пока что только гугл продемонстрировали коллизию для SHA1 пару лет назад.
А я вот не совсем понял. С одной стороны говорится, что у хэша есть детерменированность, а с другой приводится пример коллизии, где два разных пароля, но на выходе один и тот же хэш. Т.е. если пользователь вводит свой пароль, потом он преобразуется хэш-функцией в хэш и сравнивается с хэшом из бд, то это значит что каждый раз этот пароль преобразуется в один и тот же хэш. Тогда как другой пароль может преобразоваться в такой же хэш?
Да. Несколько паролей может привести к одному хешу. Это понятно чисто физически - если хеш длиной, например, 256 бит, а входные данные любые - то очевидно, вариантов входных данных больше (теоретически, бесконечно) чем может быть вариантов хеша (2 в 256 степени). То есть - да, какие-то строки будут иметь совпадающие хеши, и если хакер подберет другой пароль, который приведет к тому же хешу, что и ваш - его пустит в систему как вас. Это называется "коллизия", и обычно хеши делают достаточно случайными, чтобы коллизию было очень сложно подобрать. Те же функции, для которых коллизии становится подобрать легко (учитывая растущие мощности компьютеров), постепенно выводят из оборота, например, RC4 или MD5.
@@bigblueboar еще можно использовать алго с смещенным центром тяжести времени. тоесть каждое смещение и перетасовка данных занимает время. например 0.000231 секунды и это время можно ставить с следующий вариант перетасовки случайности. так как каждый пк будет иметь свой собственный временной лаг то и результат всегда будет разный.
@@crypto_inside это по сути и есть криптосистемы? А если какие-то алгоритмы используют хеш функции, то это уже криптоалгоритм будет, а не криптосистема? (На хеш функциях)
объясните пожалуйста, если я узнаю хэш логина и пароля в БД, то почему я не смогу авторизоваться на сайте, отправив эти хэши на сервер? там идет какая то встречная проверка что я ввел?
Если ты отправишь логин (как правило, он не хешируется, а хранится просто так), и хеш пароля - то да, авторизуешься. Только чтобы добыть этот хеш - тебе придется взломать базу данных, где эти хеши хранятся. А если уж ты ее взломал - то можешь дописать туда любые пароли, какие захочешь.
Стоп, если используя какой то алгоритм для хеширования, то почему нельзя создать обратный алгоритм? Мне просто интересно, разве если что то "собронно" то его же можно и "разобрать"
@@crypto_inside из видео осталось непонятным, где хранится соль и как она вообще формируется. Ну а она явно должна где-то храниться, так как сам пользователь даже ничего не знает о ее существовании.
@@SP-yz3wj неверно. Вы забываете, что эту соль нужно однозначно повторить на стороне сервера. На основании пароля никак, так как сервер получает не пароль а хэш от него. Скорее всего соль или передается с клиента или рассчитывается на основании открытых данных, например от имени пользователя. Я бы тоже хотел прояснить этот вопрос для практики
Я хочу хахэшировать свой пароль чтобы хранить не его в коде, а его хеш-сумму Но при этом я хочу чтобы если я ввожу пароль, а не его хеш, он все равно считал пароль правильным ЯП - python Как мне это сделать?
Ты вводишь пароль, программа считает его хеш (возможно хеш неправильного пароля, а возможно и правильного), и сравнивает с тем, что ты хранишь в коде. Одинаковый? Пароль верный.
Единственное что не до конца понял, так это то, каким образом добавляется соль, а именно то, как еë выбирают и т.д.. У меня мысль, что как соль можно использовать логин, но там тоже возможно повторение. Тогда нужно заставлять пользователя вводить уникальный логин. Наверное, бурду смолол, но ладно.
Автор так и не рассказал какой механизм создания ХЭШ функций. Больше всего ждал что узнаю как ХЭШи создаются , но автор рассказал только о том где они применяются, какие у них свойства итд., а как они создаются - нет.
@@boper7530 это оочень неверный ответ. Если бы так, то коллизий было бы уйма. Это спец алгоритмы, зависящие от аргументов. Например деление на простые числа - как примитивная функция
Вы говорите что функция не должна быть быстрой что бы ее не перебрали брутфорсом. А далее вы говоричто что идеальная функция должна быть быстрой. Противоречите сами себе.
Это и не противоречие. Это проблема, и для каждого случая решается по-своему. Иногда надо быстро - например, пользователь не будет ждать минуту, пока вычислят его хеш, и проверят пароль. А иногда лучше медленно - пусть проверяется долго, зато взломщик не сможет миллиардами перебирать чужие хеши. Все зависит от баланса между удобством и защищенностью.
☑️Рекомендую лучший VPN NordVPN - bit.ly/2kIBhVe
☑️Поддержать канал: 13oktSsmKABarzdfdYUFnvkX47keJVbgNG
☑️Наш канал в Telegram - t-do.ru/crypt0inside
автор выпустил этот видос 5 лет назад, а помог мне сегодня. спасибо вам большое
Тому кто сделал это видео всего самого хорошего в жизни! Просто, понятно, без воды!
Очень коротко, понятно и без воды. Спасибо!!!
Оуу вау, информация оч крутая и важная, даже для общего развития. + Подача и голос. Вообщем.... Чем круче контент, тем меньше просмотров и подписок
Эт не так работоет
Скорее чем контент умней, тем меньше. Ведь людям А4 смотреть хочется...
@@tauookie we live in society...
Здорово. И очень понятно. Сегодня писал авторизацию и использовал bcrypt. Но не мог понять из доков да и так, что такое хэширование. Написал как-то, а сейчас в 4 часа ночи посмотрел видео, и все верхнеуровнего стало понятно :)
Спасибо :)
Спасибо, 20 лет пользуюсь компами и только теперь узнал, что такое хеш и зачем он нужен. 😆
Та же фигня, но аж с 26.12.1996)
А мне и 20 лет нет ахах))
@@topsy9818 ахах
@@DonPorolon хақ 3 33ртy. Vyzsz9ссч"сс090фп&пса*не 2 вы вы ы0@
Херaль тут удивительно
Спасибо! Доступным языком и без воды объяснил, что это и для чего нужно и какие есть нюансы 👍
Отличный материал для человека который хочет познакомиться с данной темой.
Интересное и абсолютно понятное видео! Благодарю за информацию добрый человек :)
Душевная благодарность за очень полезную информацию и супер простое объяснение ! Удачи каналу !!! Подписался, конечно - "одобрил"
5:54 утверждение "придется перебирать все возможные значения соли" -- неверно. обычно, соль хранится вместе с паролем, и она известна. смысл соли в том, чтобы избежать именно атаки по радужным(отимизированным для поиска хеш => исходная строка) таблицам, т.е. hash(x) = y1, а hash(x + C) = y2, при этом y1 и y2 различаются кардинально (в силу того самого пресловутого лавинного эффекта). допустим, построить таблицу без соли легко для всех возможных значений x, но тогда придется построить словарь для каждого значения соли, что уже довольно затруднительно. но перебирать ее не нужно, принципиально, иначе бы пользователь при вводе пароля должен был бы помнить эти же самые рандомные значения символов, которые добавляются к его паролю :)
Разумный текст. Подскажи как на практике работают с солью. В ролике она показана динамическая (разная для разных юзеров). Как тогда на сервере ее воспроизводят для нужного пользователя? За что зацепиться серверу ( ведь логин пользователя в открытом виде не передают). Или ее тупо генерят на клиенте и отдельным параметром передают на сервер в каждом запросе авторизации. А логин и пароль превращают в хэш и передают только его.
@@mdyrhino как я и сказал, на практике чаще всего ее просто хранят вместе с хешем пароля. и да, для каждого пароля она своя -- генерится автоматически, когда хешируется пароль (иначе можно построить предподготовленные таблицы с конкретной солью, но об этом позже). если раньше (лет 10 назад) надо было париться над тем, куда и как ее вставлять, сейчас все делают библиотеки. пример довольно стандартного представления "хеша" пароля: `$5$rounds=5000$usesomesillystri$KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6` (взято из документации crypt в пхп), здесь долларами разделяется:
1. $5 -- код алгоритма хеширования (в данном случае, sha256),
2. $rounds=5000 -- параметры конкретно для данного алгоритма хеширования. в данном случае, rounds=5000 означает, что sha256() был применен 5000 раз.
3. $usesomesillystri -- та самая соль
4. $KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6 -- сам хеш пароля
как работает функция проверки пароля (скажем, password_verify в пхп или другие аналогичные): на вход поступает сам пароль, который ввел пользователь +вот эта вот строка, которую я показал выше. внутри функции мы определяем, что код 5 -- значит надо делать sha256, по параметрам смотрим, что надо это делать 5000 раз, соль такая-то, ну и значит нам надо сделать что-то вроде
```
$salt = 'usesomesillystri';
$hash = $password . $salt;
for ($i = 0; $i < 5000; $i++) {
$hash = sha256($hash);
}
if ('KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6' === $hash') {
return true; // для наглядности
} else {
return false;
}
```
к чему я это: да к тому, что соль почти всегда хранится вместе с паролем, и если утек куда-то хеш, то значит, с вероятностью (99.9%) утекла и соль. Надо сделать исключение на случай всяких людей с ФГМ, которые придумывают "свое шифрование", хранят соль отдельно, скажем, в файлике. потом, при переносе на другой сервер базу перенесли, а вот про файлик этот забыли, и кирдык, больше ни одного пароля на валидность проверить стало нельзя.
На самом деле в этом и нет никакого смысла, еще раз: соль нужна только для того чтобы не было атаки по предподготовленным таблицам (коих уже миллионы в сети). т.к. выход функции ограничен N-битами (скажем, md5() -- 128 бит, sha1() -- 160, sha256() -- 256 итд), первое, что приходит в голову всем, кто знаком с крипто-хешами, наверное, первое что приходит в голову -- взять и подбирать все возможные строки, делать, скажем, `md5($input)` и складывать все это дело в файлик. и вообще можно полностью покрыть все эти 128 бит (на самом деле, ПОЧТИ все), скажем, используя не один, а сотни компьютеров, или даже спец устройств (скажем, fpga). но просто так в файлик все не сложишь, даже в случае 128ми битного хеша, как md5 (т.е. нам понадобится хранить 2^128 значений -- таких жестких дисков еще не придумали, и даже все компы мира не смогут хранить такое количество информации, по крайней мере в 2021ом году). Поэтому был придуман алгоритм хрананения таких таблиц, и назвали его "радужным" (не помню уже, почему именно "радужный", но не суть, так назвали) -- и в итоге говорят, "чтобы не было атаки по радужным таблицам", имея ввиду на самом деле именно любые преподготовленные таблицы :)
В общем, суть в том, что если пароль не солится, то его можно просто найти в таких таблицах (которые годами генерятся на куче компов), и получить строку, хеш от которой равен тому, что вы указали. Но если изначально пароль "посолить", то вы получите совершенно другую строку (вот нельзя прям взять и перебрать все возможные строки на входе -- их бесконечность. добавление соли делает строку, скажем, на 16 байт длиннее, а даже перебрать все возможные варианты из 16ти байт вроде как нельзя, иначе бы AES128 был бы такой себе алгоритм :)), и даже если была бы теоретическая возможность получить 100% покрытие всех хешей -- это не поможет, вы просто получите ДРУГУЮ строку, у которой хеш равен тому, что вы указали (т.е. в случае соленых паролей вам могло бы показаться, что вы получите изначальный вид password + salt, но нет, скорее всего это будет просто совершенно другая строка, просто хеш у нее совпал. и проверку на password_verify она не пройдет. хотя, конечно, может вам дико повезет, но нет, вероятность такого события считается мизерной, проще купить лотерейный билетик и выйграть джекпот:) ). Вот для этого пароль солится. сама по себе соль -- это открытая информация, никто ее сильнее чем сам хеш, как правило не скрывает, ибо в этом нет смысла.
@@mdyrhino по поводу остального, как правило, в хеш превращается только сам пароль, поскольку это и есть тот самый "секрет", который знает только сам пользователь. вообще, по идее, можно было бы хранить и сам пароль как таковой, и вообще не париться над хешем. но просто люди часто используют один и тот же пароль на разных сайтах, и все это делается лишь для того, чтобы админ какого-то мелкого сервера не мог залогиниться, скажем, под вашей почтой:) (а поверьте, у админа есть доступ к хешам, да-да). и вот не имея понятия, что там за пароль, можно узнать, правильный ли пароль ввел пользователь. но нельзя узнать сам пароль. поэтому же, само собой, его можно изменить. но не узнать :) (хотя, на самом деле, вру, само собой можно при наличии доступа к коду на сервере, куда-то отдельно складывать то, что ввел пользователь, разумеется, но "честным" админам обычно это не нужно, а вот условному злоумышленнику, который каким-то образом получил доступ к базе -- да. да, конечно, плохо, что получили доступ к базе. но мы, программеры, не супермены, и иногда делаем ошибки. собственно, основное предназначение хеширования паролей -- это на случай, если что-то утечет, чтобы злоумышленник не мог получить исходный пароль у всех пользователей. ему точно так же придется перебирать кучу всяких разных вариантов, и поэтому тут оченнь важно, чтобы хотябы сам пароль был не словарный, и достаточно длинный -- тогда даже при наличии хеша его не узнают)
да, учитывайте, что видео на ютьюбе -- это в первую очередь, развлекательные, а не познавательные. к примеру, я не спорю, что "идеальная криптографическая хеш-функция" должна вычисляться быстро. (слайд "свойства идеальной криптофункции", 3:00). на практике же не придумали ничего иного, кроме как именно усложнять саму функцию, за счет чего перебор хешей становится тупо нерентабельным. всякие scrypt и bcrypt "гордятся" именно тем, что скорость вычисления их -- это порядка 33-50 хешей в секунду на средней видюхе (на той же самой видюхе md5 -- это 50e9 хешей в секунду), и как ни странно, на обычном проце скорость может быть даже выше. в общем, уходят от идеи "быстрого" вычисления. но именно "идеальная" -- да, должна вычисляться быстро. но пока никто в мире не знает, как это сделать :D
отсутсвие коллизий -- это опять таки, теоретическая штука. коллизии есть всегда, поскольку исходных строк бесконечность, а выход -- это всегда ограниченное число бит. коллизии есть всегда. их нет только в теории. но т.к. видео якобы именно о теории, я с этим ни в коем случае и не спорю :)
лично для меня эта, казалось бы, мелкая и незначительная, но принципиально неверная фраза просто говорит о том, что автор (возожно, сценарист, или даже технический консультант) недостаточно разобрался в том, как работает крипто-хеширование. остальное, скорее всего, было взято из "Прикладной криптографии" Шнаера (а может и тупо с вики, не знаю), но в общем и целом более-менее грамотно, других прям явных косяков (именно с точки зрения технической части) не заметил.
остаются, конечно, вопросы, скажем: откуда вам известно, какое хеширование используется в twitter или dropbox. у них в документации так написано? почему бы не указать было ссылку в конце видео? или вы сами ломали и twitter и dropbox, и точно знаете, что у них в первом параметре, после доллара, стоит 2y ? :D
ну или автор успел поработать и там и там, получил и там и там админские доступы к паролям, и после этого снял это видео?:) конечно, понятно, что скорее всего, bcrypt, и наврядли сами разрабы будут это отрицать, но блин, почему отсылки именно к крупным вендорам?
но это все -- косяки маркетинга, просто не упоминая названия крупных брендов, видимо, видео не раскрутишь, или я не знаю... ) с технической стороны в целом более-менее грамотно, для себя узнал, что ничего нового на ютьюбе не узнаю, по крайней мере в той сфере, в которой сам немного разбираюсь :D
привет, очень помог, учусь на кафедре кибербезопасности и защищал лабораторную работу по хэш-функции видео очень помогло при защите
Рад, что смог помочь :)
Не, ну бля везет же людям(
что за ВУЗ?
Спасибо, как раз собирался гуглить, что это такое :)
Если у тебя фиксированная длина выходной строки, а входная не ограничена, то колизии непременно будут что бы ты не делал. Это следствие из требований входных параметров.
Отличное видео, просто, понятно и доступно)
Спасибо!
Вопрос: а соль, которая добавляется к хеш функции пароля, каждвй раз генерируется случайно? Если да, то как тогда сравнивать пароль при авторизации и изначально введенный пароль пользователя?
Спасибо! Очень доступно. Именно то, что я искал
Рад, что смог помочь.
Всё очень понятно, спасибо.
Спасибо за подробное и понятное объяснение!
Круто! Спасибо! очень доходчиво и информативно!
Кратко и понятно. Респект!
Спасибо! Есть так же просто про хэш-таблицы?
Для хеширования паролей используется "соль", но она же тоже где-то должна храниться, и заполучив хеши и связанные с ними "соли" можно так же само вычислить хеши для наиболее часто используемых паролей. Так же получается?
Нет. Соль нужна для предотвращения атаки радужной таблицей.
@@brsbrs9275 нет. Антон, верно сказал. Соль не поможет при слабом пароле.
Тут в другом вопрос. В ролике показано применение разной соли для одинаковых строк пароля. Но как сгенерировать разную соль для разных пользователей, чтобы ее мало того чтобы запомнить и но каким то защищённым образом передать на сторону сервера, чтобы прошла авторизация Разных пользователей с одинаковым паролем но разно-сгенерированной солью. В ролике не рассказали про эти механизмы генерации разной соли и способы ее воспроизведения на проверяющей (серверной) стороне. Ее что в открытом виде в запросе вместе с хэшем передают? Или существует еще одна хэш функция, которая на стороне сервера однозначно генерирует ту же соль, например от имени пользователя. Кто пояснит как соль на практике реально работает?
This is awesome, very informative and simple.
2:48 почему детерменированность нарушается в 4:53
Т.е. если хеш функция однонаправленная значит и то, что и сама администрация условного вк не сможет получить доступ к моей странице если у меня сложный пароль? Т.е. зайти на аккаунт и написать от моего имени кому-то сообщение, например
Классное видео! Очень полезное для меня оказалось.
Благодарю автора за видео
Супер! Спасибо! 🤓🤝
А что мешает получив хэш из украденой БД сервиса, осуществить авторизацию без пароля, чисто по хэшу? Ведь сервис сверяет полученный от пользователя хэш с хэшем в базе и по идее ничего не мешает обойти этап получения хэша из пароля и сразу отправить сервису хэш пароля получив доступ к аккаунту.
Как выглядит результат работы защиты дропбокса? Мы там прогоняем хэшсумму предыдущего алгоритма через последующий? алгоритм? Или плюсуем хэшсуммы исходного текста, который прогнали через hash, bcrypt, AES?
Так просто за соль сказал, как будто это тупо рандомная строка подмешивается к паролю. Сделал я однажды такое в приложении, потом по своему же паролю юзер не мог войти. Соль - это не просто
Спасибо за материал ♥
Я вот так и не понял, разве требование уникальности хэша не противоречит тому, что должно быть как можно меньше коллизий? Типо ведь чем больше коллизий, тем больше надо проверить, нет?
Я тут подписалась на бесплатный курс на Coursera, но там что-то сложновато для меня. У вас намного доступней.
Ахах, для меня тоже
Извините, если я правильно понял, то шифрования недостаточно так-как можно вычислениями вывести изначальное данное. А хэш, это допустим просто рандомные цифры и буквы, которые не имеют связи с данными, а просто называют их?
Не совсем понял один момент. Как получатель программы понимает, что принятая им подпись в виде хеша является подписью именно автора программы, а не кого-либо ещё?
На сколько процентов будет надежным пароль созданный при помоши sha256 ?
В том то и дело что хэш функция создает отпечаток информации, но не уникальный! Поскольку хэш функция отображает пространство большего числа аргументов на меньшее по числу вариантов пространство результатов за счет свертки. Именно свертка не дает однозначно узнать аргумент хэш функции при обратном преобразовании. Другими словами всегда существует несколько разных паролей имеющих одинаковый хэш ))) Рейнбоу тайблс это подтверждат!
Молодцы ребята👍🏻
Класс! Очень понятно, спасибо :)
супер цікавий відос
А почему сайты хранят только хэш от пароля и логина, а логин не хранят?
А как проверять совпадение паролей при таком солировании?
Подскажите.SHA512 как работает? В смысле,сначала хеш создаётся?и потом число своё туда вставить можно?
Очень информативное видео!) Только не понятно, как блок в блокчейне хранит свою хэш сумму, если хэш сумма основана на информации, хранимой в блоке (получается включая саму хэш сумму), получается некий парадокс :-/
нет, не блок хранит свой хеш, а блок хранит хеш предыдущего блока, например:
БЛОК 1:
БЛОК 2:
,
БЛОК 3:
,
БЛОК 4:
,
И так далее. Хранение хеша в блоке, самого блока технически невозможно.
спасибо, стало понятнее!
Я: Пытаюсь узнать пароль от своего давно утерянного аккаунта имея только адресс электронной почты и Хеш пароля.
Видео каждые 2 минуты: можно взломать аккаунт вот так, но уже придумали как это полностью нейтрализовать.
Привет, расскажи как действует децентрализованная биржа ? Можно к примеру Binance DEX
Отличная идея. Обязательно сделаю видео, только не буду обещать когда, так как еще много роликов надо сделать.
Видео - бомба!
Только вот один небольшой нюанс: криптографическая хэш-функция не должна вычисляться быстро, чтобы быть устойчивой к брудфорсу
классно когда люди пишут комментарии, не досматривая видео до конца)
это что получается я такой качаю с торента win 10 и там есть md5 сумма выходит что её могут подделать
Да могут. Только это не так просто сделать. Md5 уязвима к коллизиям, но найти эти коллизии достаточно сложно. Легче чем в других, современных хэш алгоритмах, но все равно сложно и требует времени.
В торрент файле уже есть защита в виде SHA1 хешей. Если другой пользователей тебе пересылает кривой кусок, твой торрент клиент его не примет. Для SHA1 хоть и возможно построить коллизию, но нужно иметь супер компьютер, что бы сделать это. Пока что только гугл продемонстрировали коллизию для SHA1 пару лет назад.
Благодарю!
А я вот не совсем понял. С одной стороны говорится, что у хэша есть детерменированность, а с другой приводится пример коллизии, где два разных пароля, но на выходе один и тот же хэш. Т.е. если пользователь вводит свой пароль, потом он преобразуется хэш-функцией в хэш и сравнивается с хэшом из бд, то это значит что каждый раз этот пароль преобразуется в один и тот же хэш. Тогда как другой пароль может преобразоваться в такой же хэш?
случайность малая.
но сам хэш не случайность) его реально обратно разобрать) при этом даже если изначальный текст был больше 256 мегобайт.
Да. Несколько паролей может привести к одному хешу. Это понятно чисто физически - если хеш длиной, например, 256 бит, а входные данные любые - то очевидно, вариантов входных данных больше (теоретически, бесконечно) чем может быть вариантов хеша (2 в 256 степени). То есть - да, какие-то строки будут иметь совпадающие хеши, и если хакер подберет другой пароль, который приведет к тому же хешу, что и ваш - его пустит в систему как вас. Это называется "коллизия", и обычно хеши делают достаточно случайными, чтобы коллизию было очень сложно подобрать. Те же функции, для которых коллизии становится подобрать легко (учитывая растущие мощности компьютеров), постепенно выводят из оборота, например, RC4 или MD5.
@@bigblueboar еще можно использовать алго с смещенным центром тяжести времени. тоесть каждое смещение и перетасовка данных занимает время. например 0.000231 секунды и это время можно ставить с следующий вариант перетасовки случайности. так как каждый пк будет иметь свой собственный временной лаг то и результат всегда будет разный.
Какие есть криптосистемы на хэш функциях? Я так понимаю криптосистемы это ведь не криптоалгоритмы, а что-то больше?
Большинство, если не все криптовалюты использую хеш функции в том или ином виде.
@@crypto_inside это по сути и есть криптосистемы? А если какие-то алгоритмы используют хеш функции, то это уже криптоалгоритм будет, а не криптосистема? (На хеш функциях)
объясните пожалуйста, если я узнаю хэш логина и пароля в БД, то почему я не смогу авторизоваться на сайте, отправив эти хэши на сервер? там идет какая то встречная проверка что я ввел?
На сервер отправляется хэш-сумма логина и пароля, как я понял. У тебя не получится отправить один только хэш
Если ты отправишь логин (как правило, он не хешируется, а хранится просто так), и хеш пароля - то да, авторизуешься. Только чтобы добыть этот хеш - тебе придется взломать базу данных, где эти хеши хранятся. А если уж ты ее взломал - то можешь дописать туда любые пароли, какие захочешь.
Стоп, если используя какой то алгоритм для хеширования, то почему нельзя создать обратный алгоритм?
Мне просто интересно, разве если что то "собронно" то его же можно и "разобрать"
@Михаил та я сам не знаю
теперь понятно как ломаю системы )
Достойное объяснение!!!!!
Спасибо!
Ничего не понял, но очень интересно 😅
Очень крутое и интересное видео, спасибо большое
Здорово, спасибо)
Спасибо за урок
не знаю как год назад, но сейчас точно на изи можно из хэша md5 получить логин или пароль
Шикарный материал
Спасибо что понятно объяснили
а что такое коллизии? Я нигде информацию по этому вопросу найти не могу. Что это именно такое?
Коллизия, это когда из разных входных данных получается одно и то же значение ХЕША.
@@crypto_inside из видео осталось непонятным, где хранится соль и как она вообще формируется. Ну а она явно должна где-то храниться, так как сам пользователь даже ничего не знает о ее существовании.
@@phat80 узнал где она хранится?
@@phat80 как и сервер, где она должна быть воспроизведена однозначно, да еще в зависимости от пользователя
Спасибо большое!
скиньте ссылку на сайт по вычислению ХФ (крекстейшн :D). Заранее благодарю
crackstation.net
Можно просто пропустить пароль и войти в аккаунт
Не нравиться кодированном б любая кодировка это уравнение т.е.щаранее запрограммированный путь..нужно рандомно..
Откуда берется Соль ? Так и не понял
У соседа спи#дили, а вообще это наверное случайно-генерируемое число на основе пароля
@@SP-yz3wj неверно. Вы забываете, что эту соль нужно однозначно повторить на стороне сервера. На основании пароля никак, так как сервер получает не пароль а хэш от него. Скорее всего соль или передается с клиента или рассчитывается на основании открытых данных, например от имени пользователя. Я бы тоже хотел прояснить этот вопрос для практики
@@mdyrhino Ну ничего страшного. Мне кажется что соль можно взять с хеша пользовательских данных (как вы и говорили)
Боле менее надёжно будет пароль это в 50 символов а лучше 256 битное шифрование!
Лайк не глядя!
Я хочу хахэшировать свой пароль чтобы хранить не его в коде, а его хеш-сумму
Но при этом я хочу чтобы если я ввожу пароль, а не его хеш, он все равно считал пароль правильным
ЯП - python
Как мне это сделать?
Тупо условие в функции типа:
if (str == password || str == hash(password))
Ps: на синтаксис забей, считай что это псевдокод
Так в чем проблема?)
Ты вводишь пароль, программа считает его хеш (возможно хеш неправильного пароля, а возможно и правильного), и сравнивает с тем, что ты хранишь в коде. Одинаковый? Пароль верный.
Единственное что не до конца понял, так это то, каким образом добавляется соль, а именно то, как еë выбирают и т.д.. У меня мысль, что как соль можно использовать логин, но там тоже возможно повторение. Тогда нужно заставлять пользователя вводить уникальный логин. Наверное, бурду смолол, но ладно.
Лайк за отличный контент
Прям очень хорошее видео
Оооочень поверхностно
ничерта не понял, сам два года учу frontend и всегда ничего не понимаю
Супер!!!
голос как у ильи галкина. дай ссылку на альтиум
Про фейсбук не согласен)
Очень хороший
Автор так и не рассказал какой механизм создания ХЭШ функций. Больше всего ждал что узнаю как ХЭШи создаются , но автор рассказал только о том где они применяются, какие у них свойства итд., а как они создаются - нет.
Я думаю генератором случайных чисел.
@@boper7530 это оочень неверный ответ. Если бы так, то коллизий было бы уйма. Это спец алгоритмы, зависящие от аргументов. Например деление на простые числа - как примитивная функция
@@mdyrhino , пожалуй, Вы правы. Спасибо.
Как создаются качественные хэши - это хардкорная математика.
Это лайк.
Чушь какая то.
Я попробовал в питоне вызвать функцию, возвращающую хеш.
Так там у чисел -1 и -2 хеш один =-2
"Шэх функция создаёт уникальный цифровой отпечаток"
Это уже не грамотно. Но не уникальный. Хэши могу совпадать у назных аргументов функций.
Вы говорите что функция не должна быть быстрой что бы ее не перебрали брутфорсом. А далее вы говоричто что идеальная функция должна быть быстрой. Противоречите сами себе.
Это и не противоречие. Это проблема, и для каждого случая решается по-своему. Иногда надо быстро - например, пользователь не будет ждать минуту, пока вычислят его хеш, и проверят пароль. А иногда лучше медленно - пусть проверяется долго, зато взломщик не сможет миллиардами перебирать чужие хеши. Все зависит от баланса между удобством и защищенностью.
круто
Кто смотрит 2021 году >>>>>
ну ето лайк
+
Интересное и абсолютно понятное видео! Благодарю за информацию добрый человек :)