Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
Хотел было сказать, что подсоленный хэш (и лучше не MD5) - это азы из азов,
но польза материала в том, что многие и об этих простых вещах не задумываются.
Всю статью ждал когда же автор наконец-то восстановит внутреннее состояние Mersenne Twister, а этого так и не произошло.
Зато в тексте куча раз говорится про то, что энтропия пароля - это свойство процесса генерации, но если модуль random и правда читает seed из urandom - то с его энтропией всё в порядке (19937 бит достаточно для любого пароля!), и зачем на этом так фокусироваться - непонятно.
Я не ставил цель в статье показать восстановление внутреннего состояния Mersenne Twister — это уже хорошо известная атака, и при желании её несложно воспроизвести. Мне было важнее объяснить, почему сам выбор генератора здесь принципиален. Возможно, чуть позже, я воспроизведу подобную атаку и расскажу о ней.
Что касается вопроса, для чего фокусироваться именно на свойстве генерации: Проблема не в том, откуда берётся seed. Даже если он получен из urandom, дальше мы имеем дело с детерминированным PRNG. А значит, при утечке достаточного количества сгенерированных значений появляется возможность восстановить внутреннее состояние и предсказывать остальные.
Например, если в компании N, DevOps для генерации “динамических секретов” использует random, и происходит утечка нескольких тысяч паролей, то при отсутствии reseed’а это уже потенциально позволяет восстановить состояние генератора и предсказывать новые значения.
Аналогично, если есть сервис, который долго генерирует пароли на одном экземпляре MT19937 без reseed’а, то восстановление состояния даёт возможность узнать как будущие, так и прошлые пароли.
Да, в этих примерах должно совпасть довольно много условий, но это не отменяет принципиальной возможности такой атаки.
Поэтому акцент на процессе генерации важен: энтропия начального seed’а сама по себе не делает генератор криптографически стойким. Именно по этой причине для таких задач и существует secrets, а не random.
По-факту сейчас любой генератор использует детерминированный алгоритм, вопрос только в мощности множества значений, а перебирать 19337 бит придется целую вечность
Мне было важнее объяснить, почему сам выбор генератора здесь принципиален.
Но вы не объяснили этого, вот в чём проблема. Вы всю статью объясняли про энтропию, которая тут вообще ни при чём, а про детерминированность есть всего пара строк.
Поэтому акцент на процессе генерации важен: энтропия начального seed’а сама по себе не делает генератор криптографически стойким.
В одноразовом скрипте - делает.
Да, если инженер или там GigaChat пишет random в одноразовом скрипте - это показатель, что он просто не понимает как криптостойкие ГПСЧ работают и зачем они нужны, и в будущем это ещё неизбежно акунется. Но здесь и сейчас со сгенерированным паролем проблем нет.
Энтропия - это свойство фрагмента информации. То, что вы почему-то решили, что энтропия должна быть мерой криптостойкости пароля криптографической системы - это сугубо ваши ожидания, что есть, как известно, ваши проблемы.
Энтропия никак не учитывает и не должна учитывать происхождение этой информации, её предназначение и так далее. Таково определение энтропии, не вы его вводили, и не вам его менять. Если вы хотите ввести новую величину (которую вы называете "реальной энтропией") - дайте ей определение, но учтите, что определение численной величины должно быть счислимым.
Вы говорите о шенноновской энтропии, где при равномерном распределении, достаточной длине строки и алфавита - энтропия будет высокой. А также его термин рассматривает строку без какого-либо контекста, и с теоретической точки зрения это верно, я даже не пытаюсь спорить, а тем более вводить термины и величины.
Я лишь говорю о криптостойкости на практике, ведь если мы введем контекст того, что есть утечка части выходов PRNG, то в таком случае распределение для атакующего уже не является равномерным, из-за чего неопределенность резко снижается.
Да, “реальная энтропия” - неудачная формулировка, правильнее было бы сказать "условная энтропия", с учётом информации, доступной атакующему.
Только криптостойкость на практике обеспечивается за счёт большой мощности множества значений и вычислительной сложности алгоритма, 19937 бит для генератора достаточная мощность, по парадоксу дней рождений нужно перебрать минимум половину значений чтобы получить совпадение с тем, которое у нас есть изначально, то есть перебрать 19936 бит, тут ни времени ни памяти не хватит
Вы говорите о шенноновской энтропии, […] А также его термин рассматривает строку без какого-либо контекста
Да нифига! Попробуйте посчитать энтропию не отдельного символа, а сообщения целиком - и весь необходимый контекст сразу же окажется рассмотрен.
Энтропия никак не учитывает и не должна учитывать происхождение этой информации, её предназначение и так далее.
Клод Шеннон с вами не согласен.
Если у детерминированного алгоритма на входе есть N бит энтропии - то и на выходе у него будет не более N бит энтропии, независимо от того, насколько длинным мы этот выход можем сделать.
Не стоит говорить за Клода Шеннона, особенно когда сами не понимаете, о чем он говорил. Если вы про седьмую теорему Шеннона, то она работает не совсем так, как вы думаете. Иначе мы могли бы, к примеру, свести энтропию любого числа к нулю, восстановив это число из нуля с помощью многократного применения функции (алгоритма) y = x + 1, ведь в каждой иттерации энтропия y (в вашей интерпретации) не может превышать энтропию x.
Если же вы посмотрите на определение информационной энтропии системы по Шеннону, то не найдете там никаких указаний на предысторию системы. Более того, энтропия, как функция состояния, принципиально не может зависеть ни от чего, кроме состояния системы. В частности, не может она зависеть и от предыстории системы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему нельзя генерировать пароли через random в Python: разбор на практике