Шифровальная машина M-209B стала прообразом первой юниксовой утилиты для шифрования паролей crypt

Кража баз паролей из взломанных систем — распространённая проблема. Особенно остро она стояла в первые годы развития Unix, когда пароли хранились в открытом виде. Утечка такой базы означала полную компрометацию системы.

Проблему решила первая в мире утилита для хэширования crypt в 70-е гг. С тех пор пароли перестали храниться в открытом виде, в базе хранились хэши. Согласно официальной документации, утилита crypt(3) до шестой редакции использовала код из эмулятора шифровальной машины M-209, которую американская армия использовала во время Второй мировой войны. В этой системе пароль использовался не в качестве шифротекста, а в качестве ключа, которым шифровалась константа. Кен Томпсон, Деннис Ритчи и другие создатели Unix думали, что это надёжный подход. Оказалось иначе.

Вскоре выяснилось, что сверка зашифрованного пароля со всеми паролями в базе выполняется со скоростью хэширования одного пароля (1,25 мс на PDP 11/70), что было явным архитектурным недостатком системы. Поэтому в конце 70-х начиная с седьмой редакции crypt(3) перевели на одностороннюю криптографическую функцию, основанную на блочном шифре DES.

Также быстро выяснилось, что люди крайне предсказуемы в выборе паролей. И появились различные инструменты, позволяющие угадывать распространённые пароли и сравнивать их с хэшированными значениями в БД. Как правило, эти инструменты используют комбинацию словарных атак, брутфорса и других методов для угадывания потенциальных паролей и их сверки с хранящимися хэшами.

Создатели Unix всячески старались усложнить взлом паролей. Уже в конце 70-х они модифицировали программу ввода паролей таким образом, чтобы стимулировать пользователей выбирать более сложные пароли. Кроме того, при хэшировании впервые начали использовать соль: при первом вводе пароля программа генерировала 12-битное случайное значение и добавляла его к паролю. При последующем вводе пароля это значение извлекалось из базы вместе с паролем и автоматически добавлялось к нему в поле ввода.


Фрагмент файла /etc/passwd (1983). Первые два символа — это соль (12-бит), затем 11 символов хэша (64-бит), источник

Тогда же в конце 70-х появились первые микросхемы для аппаратного ускорения DES.

Первый софт для брутфорса


Первые программы для взлома паролей появились сразу после того, как системные администраторы начали их хэшировать вышеупомянутой юниксовой утилитой crypt в 70-е гг. Известно, что уже в 1978 году на компьютерах PDP-11/70 запускали эмуляторы crypt для перебора различных вариантов хэшей со скоростью около 800 паролей (хэшей) в секунду.

Первыми инструментами для информационной безопасности с функцией взлома или проверки паролей стали:

  • COPS (локальный аудит Unix-систем с функцией определения слабых паролей)
  • Crack
  • Cracker Jack
  • goodpass.c и CrackLib (позже их включили в passwd, yppasswd и др.)
  • npasswd

Со временем инструменты становились более эффективными. Вскоре лидером в области технологических инноваций стал John the Ripper, разработанный компанией Solar Designer. Но с появлением мощных GPU лидерство перехватил Hashcat, который сумел более эффективно использовать возможности графических процессоров. Интересно, что первой в мире брутфорс на GPU реализовала российская компания «Элкомсофт» (Андрей Беленко).

Кроме них, среди популярных инструментов можно назвать ещё L0phtCrack и Hydra.

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

Год Платформа Софт Хэши Производительность (хэшей в секунду)
1978 PDP-11/70 эмулятор crypt 800
1988 VAX 8600 эмулятор DES-crypt 45
1994 Pentium 60 Мгц эмулятор DES-crypt с MD5 29,41
1999 John the Ripper DES-crypt 214 тыс.
1999 John the Ripper bcrypt с рабочим фактором 5 62,5
2018 риг GPU Hashcat DES-crypt 1,7 млрд
2018 риг GPU Hashcat хэши MD5 45,4 млрд
2018 риг GPU Hashcat хэши SHA-1 14,6 млрд
2018 риг GPU Hashcat bcrypt с рабочим фактором 5 47,2 тыс.
2018 риг GPU Hashcat scrypt 1,4 млн
2022 RTX 4090 Hashcat DES-crypt 6,3 млрд
2022 RTX 4090 Hashcat bcrypt 184 тыс.
С ростом производительности CPU и GPU стало очевидной важность выбора конкретного алгоритма хэширования, чтобы затруднить (замедлить) брутфорс. Многие веб-разработчики в 90-е годы использовали встроенную в PHP функцию md5() без соли, но с 2007 года там появилась поддержка phpass (bcrypt), так что индустрия постепенно автоматически переходила на более сильные алгоритмы хэширования. Средняя длина паролей тоже постепенно растёт. Если верить статистике, она увеличилась с 4,4 символов в 1989 г до 7,9 символов в 2009 году (см. "The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords", 2012 IEEE Symposium on Security and Privacy).



Можно предположить, что с массовым распространением парольных менеджеров во второй половине 2010-х длина паролей ещё увеличилась.

Новые алгоритмы хэширования разрабатываются с учётом максимальной недружественности к CPU, GPU и памяти, чтобы максимально замедлить вычисление на любом устройстве, включая FPGA и ASIC.

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

Комментарии (10)


  1. mapnik
    29.10.2023 18:33
    +5

    Разве Solar Designer — это компания? Всегда считал, что это человек.



  1. diakin
    29.10.2023 18:33

    программы для подбора паролей ... сверка зашифрованного пароля со всеми паролями в базе

    А как они работают вообще? Как они имеют доступ к базе с хэшами?


    1. avost
      29.10.2023 18:33

      А как они работают вообще? Как они имеют доступ к базе с хэшами?

      Со стороны злодея, да, работают на слитых базах. Со стороны своих админов - на своих для выявления слабых паролей и посылания "ай-яй-яй" писем потенциальным объектам атаки )).


      1. diakin
        29.10.2023 18:33

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


        1. avost
          29.10.2023 18:33

          Для хранения паролей можно замутить какие-нибудь шифрованные базы

          О чём вы? Хранить шифрованные пароли по всем параметрам хуже, чем хешированные.

          Которые сливать в том виде, как хранятся на диске бессмысленно.

          А что с ними происходит при сливе? Они взрываются? Теряют способность к расшифровке? Самоуничтожаются?
          Видите ли в чём дело. Парольные базы нужны для того, чтобы из них постоянно читать. И иногда писать. Поэтому, всегда есть моменты, когда база расшифрована. Вот тут она и сливается. И именно поэтому придуманы более удобные и более безопасные средства для работы с паролями. Такие, как хеширование. Когда открытае пароли в целевой системе не светятся вообще никогда кроме момента расчёта от них хеша.

          Есть же просто диски с шифрованием.

          Никто не запрещает хранить парольные базы на шифрованых дисках. От сливов это не защитит. Защитит от физической кражи носителей из датацентра или нарушения протокола утилизации. Да, от этого тоже надо защищаться, всё верно.


          1. diakin
            29.10.2023 18:33

            О чём вы? Хранить шифрованные пароли по всем параметрам хуже, чем хешированные.

            Базы с хешированными паролями хранить на шифрованном диске\в зашифрованном виде, как дополнительная защита от подбора по хешам.

            Поэтому, всегда есть моменты, когда база расшифрована.

            Есть разные методы - https://ru.wikipedia.org/wiki/Шифрование_базы_данных


            1. avost
              29.10.2023 18:33

              Базы с хешированными паролями хранить на шифрованном диске\в зашифрованном виде, как дополнительная защита от подбора по хешам.

              Как я и написал, никто не мешает это делать, но ни от слива ни от последующего подбора это не спасает. Сливы, в основном, делаются не путём кражи/копирования физического носителя. Другой вектор атаки.

              Есть разные методы - https://ru.wikipedia.org/wiki/Шифрование_базы_данных

              Из перечисленных там все в той или иной мере выдают расшифрованные данные по условному SELECT'у. Кроме метода "Шифрование на уровне приложений". Но именно это и делает хеширование :). Зашифровать каждый хеш сверху дополнительно, конечно, можно, но это малоосмысленно, тут полезнее усиливать функцию кеширования.


  1. Krey
    29.10.2023 18:33
    +2

    Радужные таблицы стоило бы упомянуть


  1. vasilijmooduckovic
    29.10.2023 18:33

    перелагаю тему для следующей статьи - написание собственного правила для hashcat чтобы брутить пресловутую керилицу, oneRuleToRuleThemAll.rule не канает по умолчанию (scriptKidieSadness.jpg))(