Комментарии 41
"кто-то шифровал пароль, но на MD5" - вы ведь правда знаете, что MD5 - не шифрование?
Дык ещё "Энигма" считалась невзламываемой.
Но Тьюринг сотоварищи (и "с господами"), базируясь на польских довоенных наработках и используя "духов тёмных сил" :) с ней таки справились...
Пусть расцветают сто цветов: Пришел конец былой работе криптоаналитиков! Ни больше ни меньше.
"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"!
Для защиты данных выбирайте актуальные алгоритмы:
"актуальные алгоритмы" сломают в первую очередь и вы об этом не узнаете.
Вот поэтому лучше написать свой, который никто ломать не будет.
И как проверить стойкость шифрования?
злоумышленник с той же RTX 4090 будет перебирать миллионы вариантов в секунду
А изобретатели шифрования об этом не знают?
Если знают, почему не исключили эту возможность?
И как вообще программа, подбирающая пароли,
узнаёт что пароль правильный или нет?
Про последнее: а как программа, расшифрующая архив узнает, что пароль подошел?
Ей это не нужно: она должна отработать с любым паролем.
Однако, т.к. у шифрующей и расшифрующей программ
один автор, то нетрудно предусмотреть разные проверки
или просто возложить эту проверку на пользователя, чтобы затруднить подбор пароля.
Вот. Если подбирать мастер-пароль на шифрованную базу паролей (как в статье), то в формате файла должно быть проверочное поле. Если перебирать md5 без соли, то коллизия ничтожно маловероятна и при этом ни на что не влияет. С солью - да, можно отловить ложно-позитивную коллизию. Но рассчет-то на десятки тысячи простых паролей, которые сначала базами перебираются, а потом возмооожно доламываются. Одна коллизия - капля в океане Европы.
Теперь понял причину быстрого подбора пароля:
ZIP и RAR сразу выдают "Ошибка при распаковке (неверный пароль)"
И это ещё одна причина делать свой шифровальщик.
Почему же это не исправляют?
И ещё подумал что "актуальные алгоритмы" сразу делают
уже сломанными, чтобы пройти сертификацию.
Но ведь это же может утечь в любой момент.
И как можно этим пользоваться?
ZIP и RAR сразу выдают "Ошибка при распаковке (неверный пароль)"
А что они должны выдавать вместо этого?
Они не должны выдавать это сразу
и значит хранить пароль в любом виде.
В худшем случае хранить hash или crc исходного файла
и выдавать сообщение после расшифровки всего файла.
А лучше вообще ничего не выдавать.
"ничего не выдавать" = "молча распаковывать мусор вместо исходного файла"?
Помимо файла(ов) в архиве хранится служебная информация, которая тоже шифруется. При расшифровке первой расшифровывается она, и если на выходе ерунда вместо данных - значит пароль не правильный, дальше смысла нет двигаться.
А учитывая, что её размер килобайты, и расшифровывается она быстро - на неправильный пароль потому и реагирует почти сразу.
Или вместо служебной информации используется специальный тестовый набор битов, который тоже шифруется, и дешифруется при распаковке первым. Не совпал при распаковке - не правильный пароль.
Т.е. добавить способ проверки корректности пароля, который не снижает надёжности, и сделан для удобства пользователя, не сложно.
При расшифровке первой расшифровывается она, и если на выходе ерунда вместо данных - значит пароль не правильный, дальше смысла нет двигаться.
Смысл - сделать задержку, чтобы затруднить подбор пароля,
поэтому эту информацию лучше поместить в конец файла.
И если у вас гигантский архив, то ждать расшифровки хвоста, чтобы понять, что опечатался в одном символе? А что мешает злоумышленнику расшифровывать файл с конца?)
ИБ -- это баланс между удобством, доступностью и безопасностью. Рядовому пользователю, как правило, защита будет нужна до тех пор, пока остаётся приемлемым время отклика, поэтому баланс сдвигается к удобству и доступности. (Ведь в противном случае, пользователь будет стремиться обходить эту систему защиты.)
На самом деле вы для себя можете выбрать другой алгоритм, в котором будет отсутствовать информация правильно ли вы использовали пароль. У того же AES 256 есть разные режимы работы. В режиме cbc такой проверки нет. В режиме gcm есть auth tag (по стандартам web crypto), который проверяет корректность расшифровки. Вообще, для себя ответьте как будете осуществлять проверку целостности информации, как будете защищать информацию от внесения несанкционированных изменений.
Почему же это не исправляют?
Хм, а если Вы не будете контролировать целостность данных, то Вам будут злонамеренно их изменять даже не расшифровывая. Что, соответственно, рекурсивно породит ваш вопрос: "Почему же это не исправляют?". 😉
А какая конечная цель распаковки? Как пользователь узнает, корректно ли проведена распаковка?
Легко написать алгоритм, который вы сами не можете взломать.
Гораздо сложнее написать алгоритм, который не может взломать кто-то другой.
И тут опять возникает вопрос, на который пока никто не ответил:
И как проверить стойкость шифрования?
Это доказывает, что вы даже не пытались разбираться в теме. Существует огромное количество способов проверки алгоритмов, начиная от математического моделирования, статического/динамического анализа, и заканчивая банальным фаззингом. Более того, проводятся конкурсы по разработке и проверке алгоритмов (так, например, появился AES).
"огромное количество способов проверки алгоритмов" доказывает что надёжного нет.
Доказать что сломать алгоритм шифрования невозможно невозможно?
"Надежный" не равно "неуязвимый". "Надёжный" равно "финансовые/временные/умственные затраты на взлом многократно превышают выгоду от результата".
Любой алгоритм шифрования, кроме одноразового блокнота, теоретически взламывается. AFAIK, доказано в обе стороны. Ключевое слово, как уже сказали в комментарии выше, - "теоретически".
Сотрудник ИБ знает, что решение — в перехешировании всей базы.
Я не сотрудник ИБ, и мне интересно - что здесь имеется в виду? Использовать второй хэш поверх первого?
При новій успешной аутентификации юзер сам отправляет правильный пароль на сервер и в этот момент отдельный скрипт хэширует по новым правилам пароль и новый хеш записывается в базу и старый пароль помечается как неиспользуемый. Вариантов что делать с теми, что не обновились: а) можно забить; б) прислать письмо об отключении аккаунта из-за неактивности или в) письмо про просто сменить пароль по любой причине и если нет, удалять аккаунты
ну это просто s-боксом больше..
вы не поняли сути.
упрощая детали, шифрование - это использование алгоритма. и только у НЕКОТОРЫХ алгоритмов есть ЕЩЕ ключ! в этом случае (неявно) предполагается, что алгоритм уже известен аналитику и осталось "только" угадать ключ.
так вот.
в случае тысячи школьников алгоритм уже НЕ известен! т.к. изменение любого бита зашифрованного блока сразу же портит весь блок. и все, что идет за ним.
вы не будете бегать за тысячей школьников => зашифрованный текст перестал АВТОМАТИЧЕСКИ взламываться...
Статью писала нейронка?
Из рассмотренных кейсов только 1 имеет хоть какое-то отношение к криптографии, содержание вводной части вообще не соответствует "реальным кейсам", например было бы интересно послушать про провалы из-за ужасных SHA-1 и SSLv3. По факту никаких проблем кроме KDF для хранения паролей не рассмотрено.
Как вообще с темой связаны поддельные репозитарии?
Как вообще криптография поможет в случае пароля Aleksandr1991? (ответ: никак, тяжелые хеши не спасут если качество паролей такое, что их можно брутить в онлайне, вы не можете сделать хеш затратнее чем время допустимое для проверки пароля в онлайне)
Как перехеширование базы спасет в ситуации если база уже утекла?
А объясните мне, как длина и сложность пароля влияет на скорость взлома его если итоговый хеш всегда одного размера?
Хеш обычно используется для проверки правильности пароля. Он не полностью идентичен паролю.
Хеш в криптографии часто используется для проверки целостности данных. Например, с его помощью проверяется верный ли использовался ключ.
Длина и сложность влияют на то, как быстро пароль можно набрутфорсить. По мере роста длины количество вариантов, которые брутфорс должен перебрать, растёт экспоненциально, по мере роста количества допустимых символов - прямо пропорционально.
короткий пароль перебирается, хэш сравнивается. По этому хэш pan банковских карт хранить надо также шифрованным, например, особенно рядом с маской. Мало цифр + алгоритм луна сужает доступные. Короче перебор возможен
Зашифруй или проиграешь: реальные истории провалов из-за слабой криптографии