Зачем менять надёжный пароль? Брутфорс и энтропия +6




Что такое надёжный пароль? По мере развития технологий за последние десятилетия несколько раз менялись политика, что считать таковым. Мощности для брутфорса становятся всё доступнее, в том числе в облаках, поэтому и требования к энтропии паролей повышаются — в 2022 году рекомендуется использовать спецсимволы, цифры, буквы в разных регистрах, с общей длиной минимум 11 символов.

Недавно в индустрии информационной безопасности поднялась дискуссия на тему смены паролей. В частности, появились рекомендации против периодической смены паролей. Логика в том, что пользователям сложнее учить новые пароли каждую неделю, чем запомнить один большой и сложный пароль. В 2017 году рекомендации против смены паролей опубликовала организация NIST, отвечающая за принятие стандартов парольной защиты.

Рекомендации NIST


Пароль представляет собой шаблон, слово, комбинацию или другой тип информации, который предположительно известен только пользователю и может быть проверен для подтверждения личности пользователя.

Стандарты и определения о парольной защите изложены в Специальной публикации NIST 800-63B, раздел 5.1.1.2 «Запоминаемые секретные верификаторы» (NIST, 2017).

В 2017 году NIST официально заявила, что обязательная смена пароля на самом деле значительно снижает общую безопасность системы паролей и не должна использоваться. Это объясняется в вопросах B05 и B06 в разделе FAQ документации NIST к обновлённым специальным публикациям (NIST, 2020).

Но на самом проведено крайне мало исследований, подтверждающих тезис NIST о снижении энтропии паролей при их периодической смене. Давайте разберёмся, так ли это на самом деле.

Энтропия и брутфорс


Для вычисления энтропии (E) пароля используется формула

$E=log_2(S^L)$


Расчёт количества попыток (G), необходимых для подбора пароля с вероятностью 50%, производится по формуле

$G=2^{E-1}$


  • S — размер пула уникальных символов. Некоторые составляющие пула:

    • цифры (0-9): 10
    • строчные символы латинского алфавита (a-z): 26
    • строчные и прописные символы латинского алфавита (a-z, A-Z): 52
    • набор символов ASCII (a-z, A-Z, символы, space): 95
  • L — длина пароля

Чем выше энтропия — тем лучше, а по современным меркам достаточной считается энтропия 36 бит. Например, пароль типа S@mp1ePas$word состоит из строчных и прописных букв, цифр и специальных символов ASCII длиной 14 символов. Такая комбинация даёт размер пула 95, и по формуле это соответствует примерно 4,87x1027 возможным комбинациям пароля.

Энтропия такого пароля будет рассчитана как $E=log_2(95^{14})$, то есть примерно 91,98 бит. С таким значением энтропии мы можем примерно рассчитать, сколько попыток в среднем понадобится, чтобы подобрать пароль (брутфорс 50% всех возможных вариантов). По формуле $G=2^{E-1}$ мы получаем 291,98-1, то есть примерно 2,44×1027 случайных попыток.

Это общее описание метода. В реальности злоумышленник может значительно уменьшить количество попыток с помощью словаря. Для сохранения нормальной энтропии критически важно генерировать случайные пароли в специальном программном обеспечении со стойким ГПСЧ, а не вручную.

Но в целом в индустрии принято мнение, что энтропия пароля, вычисленная по такой методике, коррелирует с его безопасностью.

Для сравнения, у пароля длиной восемь символов из строчных букв энтропия всего лишь 37,6 бит, что даёт нам среднее количество попыток 104,2 млрд. Если предположить, что компьютерная система перебирает более ста миллиардов вариантов в секунду, то такой пароль она взломает практически мгновенно даже без помощи словаря.

Периодическая смена паролей повышает энтропию


Группа исследователей из Университета Роберта Морриса (США) задалась вопросом, насколько эффективной является периодическая смена паролей. В частности, они решили проверить, насколько понижается или повышается энтропия в этом процессе.

Исследователи поставили небольшой эксперимент, в котором согласились участвовать 51 доброволец из тематических сообществ r/PCMasterRace, r/SysAdmin и r/CyberSecurity, где общаются энтузиасты компьютерных технологий.

Краткое описание эксперимента:

  1. Участников попросили создать аккаунт на сайте эксперимента и придумать произвольный пароль от 2 до 160 символов.

  2. Затем они дважды в неделю в течение двух месяцев входили в учётную запись. Вход был необходим, чтобы проверить, помнят ли участники свой пароль и могут ли они использовать его в течение длительного периода времени.

  3. В каждую пятницу пользователям предлагалось выполнить задание в зависимости от их подгруппы. Членам группы А для выполнения задания нужно было просто войти в систему без смены пароля. Членам группы В предлагалось сменить пароль каждую пятницу, а членам группы С — каждую вторую пятницу.

Система была запрограммирована на автоматическую регистрацию всех попыток входа в систему, как успешных, так и неуспешных. Система также автоматически записывала все значения энтропии пароля при каждом обновлении или сбросе пароля. Эти показатели были разработаны для того, чтобы зафиксировать, была ли у какой-либо конкретной группы более высокая частота неудачных попыток входа в систему или других ошибок при входе, а также для отслеживания участия пользователей в исследовании с течением времени.

Был написан скрипт для безопасного вычисления энтропии паролей на хосте без раскрытия или сохранения фактического значения пароля в открытом виде.

Скрипт на PHP для вычисления энтропии
<?php

//Получение имени пользователя и пароля из формы
	$savedpass = $_POST['password'];
	$saveduname = $_POST['username'];

//Вычисление энтропии
	$value = 0;
	$set = 0;
	$pattern = preg_match_all("/[A-Z]/", $savedpass);
	if ($pattern != 0)
	{
		$set = $set + 26;
	}
	$value = $value + $pattern;
	$pattern = preg_match_all("/[a-z]/", $savedpass);
	if ($pattern != 0)
	{
		$set = $set + 26;
	}
	$value = $value + $pattern;
	$pattern = preg_match_all("/[0-9]/", $savedpass);
	if ($pattern != 0)
	{
		$set = $set + 10;
	}
	$value = $value + $pattern;
	$pattern = preg_match_all("/[ -\/\:-@[-`{-~]/", $savedpass);
	if ($pattern != 0)
	{
		$set = $set + 33;
	}
	$value = $value + $pattern;

//Вычисление log2(s^l)
	$sl = pow($set, $value);
	$entropy = log($sl, 2);
	$entropy = round($entropy, 2);

//Проверка на наличие некорректных символов
	$crosscheck = preg_match_all("/[^ -~]/", $savedpass);
	if ($crosscheck != 0) {
		$debuglog = "ILLEGAL CHARACTERS IN PASSWORD!";
	}
	else {
		$debuglog = "ALL CLEAR";
	}
?>

По окончании эксперимента получены следующие результаты энтропии (до конца эксперимента продержались 28 человек):

Контрольная группа А (без изменения пароля, n=10 человек) Группа B (каждую пятницу, n=9) Группа C (каждую вторую пятницу, n=9)
Начальная средняя энтропия 71,88 96,05 77,50
Конечная средняя энтропия 71,88 160,74 95,02
Изменение средней энтропии 0 64,69 17,52

Финальный опрос пользователей из трёх контрольных групп показал, что примерно половина из них использует парольный менеджер, а каждый третий использует предсказуемый паттерн при создании нового пароля.

Тем не менее авторы делают вывод, что периодическая смена пароля скорее повышает, а не понижает их энтропию, как предполагала NIST. Хотя с учётом ограниченного размера выборки, для подтверждения найденных закономерностей необходимо провести дополнительные исследования.

Результаты исследования опубликованы в апреле 2022 года в журнале «Проблемы информационных систем» (том 23:2, стр. 29-41, doi: 10.48009/2_iis_2022_10).




Комментарии (31):

  1. ky0
    /#24888302 / +5

    Ставя на КДПВ неоднозначную картинку — хотя бы подписывайте, что на ней изображено. А ещё лучше — используйте более однозначную, как например, вот тут:

    image

  2. mortadella372
    /#24888312 / +12

    согласились участвовать 51 доброволец из тематических сообществ r/PCMasterRace, r/SysAdmin и r/CyberSecurity

    Мало того, что выборка состоит из крипто/it-энтузиастов и профи, так она еще и дополнительно скошена теми, кто согласился на эксперимент (а не решил "ну его нафиг").

    Критика частой смены паролей не относится к этим людям, она относится к обычным гражданам.

    • Moskus
      /#24888770 / +3

      Угу, социальный эксперимент нужно еще уметь поставить так, чтобы он не проверял что-то очень сильно отличающееся от того, что хотят проверить авторы идеи эксперимента.

      Тем более что анти-паттерн "энтомолог с лупой" - известен, описан и должен был быть исключен в этой ситуации простым опросом о том, как именно испытуемые придумывали эти пароли. И если там преобладали бы ответы типа "использовал генератор", все результаты должны были быть отправлены в помойку.

      Потому что "обычный гражданин" на порядки чаще использует при изменении шаблон, например - добавляет один символ, меняет один символ.

  3. SergeKh
    /#24888322 / +11

    В случае если сервер принимает соответствующие современным рекомендациям меры защиты, такие как антифлуд, соль в хэше и правильные алгоритмы хэширования, - то восьми символов в пароле будет достаточно.

    Если же сервер не принимает мер к защите - то пользователю бесполезно как-то шаманить со сверхдлинными паролями. Если вы предполагаете что сервер дырявый (т.е. можно скачать хэш) и хэш там сделан слабым алгоритмом, то почему вы тогда не предполагаете заодно что сервер вовсе хранит плейн-текст?

    • Moskus
      /#24888784 / +1

      Если в обсуждении стойкости паролей с формулами (!) не упоминается антифлуд и блокировка с эскалацией (типа принудительной смены и т.п., зависит от контекста), то это тупо сенсационалистская писанина, не имеющая к серьезному техническому анализу проблемы никакого отношения. Что не странно, потому что уже сама методология исследования - из разряда garbage in, garbage out, потому что адский selection bias.

  4. v1000
    /#24888370 / +1

    рекомендации против периодической смены паролей

    Это, скорее, попытка угодить самим пользователям, потому что больше вероятность того, что новые пароли будут записываться, и хорошо если не на бумажках, которые клеят на монитор.

    Но вот на внешних серверах пароли лучше менять, потому что довольно часто база паролей с них утекает, а так в дампе будет старый пароль.

    Ну и принцип временной блокировки аккаунта после 3-5 неудачных попыток - тоже мешает эффективному подбору паролей.

    • JPEGEC
      /#24888402

      Ну и принцип временной блокировки аккаунта после 3-5 неудачных попыток - тоже мешает эффективному подбору паролей.

      Подбор в принципе невозможен с скоростями типа "более ста миллиардов вариантов в секунду". Это все актуально исключительно при доступности хешей паролей.

      И тогда регулярная замена паролей чем-то напоминает сеансовый пароль того же https.

    • Moskus
      /#24888790 / +2

      Любое правило информационной безопасности, превращенное в ритуал культа карго, скорее - вредит чем помогает.

  5. ramiil
    /#24888630 / +11

    В каких ситуациях регулярная смена паролей помогает?
    1. От слитых хэшей паролей. Эффект - удовлетворительный, возможно успеть сменить пароль за время брута, даже если не знать о сливе хэша пароля.
    2. От брутфорса сервиса. Эффект - околонулевой, нужно бороться с самим фактом брута(банить по ip, урезать кол-во попыток, в крайнем случае - прятать сервис во внутренней сети с доступом по vpn).
    3. От слитых паролей. Эффект околонулевой(даже если менять пароли каждый день, злоумышленник успеет за это время сделать почти что угодно)

    В двух с половиной случаях из трёх(слить белый пароль в открытом виде может как сервис, так и пользователь, а вот слить хэш от пароля или позволить брутить учётку модет только сервис) в уязвимости виноват сервис, а не пользователь, так что частая смена паролей, не смотря на некоторую эффективность, нужна сервису что-бы прикрыть жопу, а не конечному пользователю.

    Теперь о минусах частой смены паролей.
    1. Пользователь забывает пароли, как результат п.2, п.3, п4
    2. Пользователь начинает записывать пароли, и создаёт ещё одно направление атаки
    3. Пользователь начинает использовать одинаковые пароли на разных сервисах, что создаёт ещё одно направление атаки
    4. Как сказано в статье, при частой смене паролей падает их энтропия, вплоть до "номерных" паролей, типа mypassword1 mypassword2, итд.

    • miarh
      /#24889488 / +1

      Есть еще один, очень частый пункт 4
      4. Пользователи частенько "делятся" своими паролями, для быстрого решения какой то задачи (я в отпуске (в отгуле, на больничном...), зайди, посмотри - на комп, в почту, на портал и т.д.). И никакие административные запреты не помогают. А этот "временно" выданный пароль легко потом может использоваться для доступа к сервисам, к которым доступа то не должно быть.
      Но да, часто менять вредно - начинаются пароли вида .... 1, 2, 3 ....

      • ramiil
        /#24889564 / -2

        В трудовом договоре есть что-то про разглашение корпоративной информации третьим лицам? Значит надо привлекать, и привлекать жестко, с увольнениями и штрафами. Если юзверьки не способны понять самые простейшие правила информационной безопасности(не запускать непонятные файлы, не пытаться отключить антивирус, не давать свой пароль кому попало) то пускай работают на менее критичной к знаниям должности, например, моют унитазы.

        • AlexeyK77
          /#24890400 / +2

          Это теоретически так, а на практике не работает как хочется ИБ, жизнь сложнее. Поэтому лучше сразу закладываться на сценарий, что "пароль передан сознательно" как уже случившийся и подстраховываться другими способами.
          Вообще в безоапсности самым слабым звеном является человек, а не технологии (за редким исключением)

          • miarh
            /#24890942 / +1

            Да, согласен. Есть правила, а есть человек. Вот что угодно можно прописать, но пароли все равно передают друг другу. Из "лучших побуждений". И лучше это учитывать. Разве есть те, кто не знает, что по ссылкам из писем " от налоговой" переходить не нужно?

  6. 2er6e1
    /#24888676 / +1

    Непонятно что изображено на картинке.

    Какой метод взлома пароля использовался? Если взлом хеша из серверной бд - то наверное зависит от типа хеша. И типа оборудования на котором взлом производится. А если взлом дистанционный - то нормальный сервер не позволит больше 3 попыток за 3 секунды, а потом кукишь покажет.

  7. dcooder
    /#24888752 / +6

    Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.

    Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.

    Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.

    • Moskus
      /#24888814 / +2

      У меня в компании нет настоящего ISO/CISO. И используется Microsoft single sign-on. И password TTL - 180 дней. И есть запрет на установку "стороннего ПО" (browser plug-in-ы под него подпадают, правда - это никто реально не проверяет). Аутентификация по смарткартам или токенам - не внедрена и, фактически, запрещена.

      Мне, как (в прошлом) PSP, это глубоко смешно. На счастье, у меня другие задачи, если компанию сломают - не моя башка полетит.

  8. herase
    /#24889530

    Сижу и пытаюсь понять, как автор получил, что пароль из 7 символов a-z,A-Z,0-9 ломается за 7 секунд. Это $62^7 = 3.5 * 10^{12}$ вариантов. Если система позволяет попытки раз в секунду, то это 111 тысяч лет. Откуда взялись 7 секунд?

    • AlexeyK77
      /#24890172

      Речь об оффлайн брутфорсе хэша пароля. Хэш пароля получается уже в результате атаки на протокол (разнообразие методов атак на протокол в сетях мкрософт), прослушивание трафика в рузультате удавшегося спуфинга и банального слива БД с хэшами пароля веб-приложений по причине наличия логических уязвимостей.

  9. wadowad
    /#24889602 / +1

    Объясните мне, каким образом длина пароля влияет на уровень защиты, если всё равно сверяется хэш, а не сам пароль? Длина хэша ограничена и хэш длинного пароля может совпадать с хэшем более короткого пароля. Говоря проще, после какого-то определённого значения длина пароля не будет иметь никакого смысла. Или я что-то неверно понимаю?

    • SomeAnonimCoder
      /#24889860

      Зная пароль - злоумышленник может войти куда-то, особенно если пароли везде одинаковые. Зная коллизию - не факт, ибо есть соль, есть разные алгоритмы хеширования, и т. д.

    • playermet
      /#24891134 / +4

      Речь вероятно о поделиях, технологически сопоставимых со школьными лабораторными работами, которые еще не додумались блокировать множественные проваленные попытки аутентификации, и которые можно брутфорсить в лоб. В современной реальности гораздо актуальней уникальность паролей для каждого сайта/сервиса, чем их длина.

      Да и вообще в статье проверяется не то, что следовало бы. Проблема частой смены паролей в том, их сложно запомнить. И если гик добавит запись в менеджер паролей, то простой обыватель запишет его на бумажке и приклеит к монитору. Вот - корень проблемы, а не энтропия пароля который завтра нужно придумать.

    • Deosis
      /#24892066

      У популярных функций хеширования размер блока от 256 бит. Это 32 символа.

      Можно считать, что разные пароли меньшей длины дадут разные хеши.

      Но даже для более длинных паролей коллизия может содержать непечатные символы.

      Злоумышленнику проще перебрать 20-ти символьную последовательность, чем 32-х байтовую.

      Поэтому, грубо говоря, уровень защиты растет вместе с длиной пароля до длины блока хеша.

      • wadowad
        /#24896270

        Вы говорите о каких-то продвинутых ресурсах. В реальности на колоссальном количестве сайтов имеем MD5 без соли и 128-битные хэши.

  10. Revertis
    /#24890482

    Тем не менее авторы делают вывод, что периодическая смена пароля скорее повышает, а не понижает их энтропию, как предполагала NIST.

    А дело всего лишь в том, что когда сайт требует сменить пароль юзер считает, что админы сайта зачем-то сильно беспокоятся о безопасности аккаунта юзера, значит и юзеру надо сильнее беспокоиться и поставить пароль сложнее.

    Короче, тупо манипуляция.

  11. johnfound
    /#24890718 / +1

    S@mp1ePas$word

    А это вообще-то словарный пароль. Меняй — не меняй буквы на символы.

  12. semennikov
    /#24891612

    С моей точки зрения 99,(9) взлома паролей исключительно социальная, через людей. Единственная причина смены паролей которая действительно может помочь — это блокировка старых пользователей(например уволившихся)

    • Moskus
      /#24891976

      Порядка 70% через фишинг, согласно некоторым источникам.

      • semennikov
        /#24893504

        Так фишинг и есть одна из разновидностей социальной инженерии, они же не взламывают пароли перебором

        • Moskus
          /#24896012

          Мне всегда интересно, зачем люди возражают тем, кто с ними (частично) согласен. Мой комментарий был о том, что преобладание фишинг, но до 99% это всё же не дотягивает.

  13. semennikov
    /#24897140

    Я видимо не совсем правильно понял Ваш комментарий. Тогда попробую сформулировать свое мнение так:

    Способ 99,(9) взлома паролей исключительно социальный, через людей(и из них 70% это фишинг). Единственная причина смены паролей которая действительно может помочь — это блокировка старых пользователей(например уволившихся)

  14. tolik_anabolik
    /#24897460 / +1

    Не примите за личное, но в:

    	$sl = pow($set, $value);
    	$entropy = log($sl, 2);

    нет смысла вычислять степень... школьный курс математики говорит, что логарифм от степени, это произведение степени на логарифм, т.е.

    $entropy = $value * log($set, 2);

    это вас обезопасит от переполнения double в случае с большими числами.

    Другой момент, то как вы вычисляете набор символов для энтропии. Первое, preg_match_all вообще не для этого придуман, и вам нужен простой preg_match. Второе, вы очень смело ограничили пароли только латиницей и странным набором спец. символов, словно другие наборы символов не могут быть использованы. Ну и третье, намного проще, и наверно даже правильней, собирать набор по самому паролю, т.е. вычислять просто кол-во уникальных символов в предоставленном пароле, полагая что злоумышленник знает этот набор.