Шифровальная машина 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 тыс. |
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)
diakin
29.10.2023 18:33программы для подбора паролей ... сверка зашифрованного пароля со всеми паролями в базе
А как они работают вообще? Как они имеют доступ к базе с хэшами?
avost
29.10.2023 18:33А как они работают вообще? Как они имеют доступ к базе с хэшами?
Со стороны злодея, да, работают на слитых базах. Со стороны своих админов - на своих для выявления слабых паролей и посылания "ай-яй-яй" писем потенциальным объектам атаки )).
diakin
29.10.2023 18:33Для хранения паролей можно замутить какие-нибудь шифрованные базы. Которые сливать в том виде, как хранятся на диске бессмысленно. Есть же просто диски с шифрованием.
avost
29.10.2023 18:33Для хранения паролей можно замутить какие-нибудь шифрованные базы
О чём вы? Хранить шифрованные пароли по всем параметрам хуже, чем хешированные.
Которые сливать в том виде, как хранятся на диске бессмысленно.
А что с ними происходит при сливе? Они взрываются? Теряют способность к расшифровке? Самоуничтожаются?
Видите ли в чём дело. Парольные базы нужны для того, чтобы из них постоянно читать. И иногда писать. Поэтому, всегда есть моменты, когда база расшифрована. Вот тут она и сливается. И именно поэтому придуманы более удобные и более безопасные средства для работы с паролями. Такие, как хеширование. Когда открытае пароли в целевой системе не светятся вообще никогда кроме момента расчёта от них хеша.Есть же просто диски с шифрованием.
Никто не запрещает хранить парольные базы на шифрованых дисках. От сливов это не защитит. Защитит от физической кражи носителей из датацентра или нарушения протокола утилизации. Да, от этого тоже надо защищаться, всё верно.
diakin
29.10.2023 18:33О чём вы? Хранить шифрованные пароли по всем параметрам хуже, чем хешированные.
Базы с хешированными паролями хранить на шифрованном диске\в зашифрованном виде, как дополнительная защита от подбора по хешам.
Поэтому, всегда есть моменты, когда база расшифрована.
Есть разные методы - https://ru.wikipedia.org/wiki/Шифрование_базы_данных
avost
29.10.2023 18:33Базы с хешированными паролями хранить на шифрованном диске\в зашифрованном виде, как дополнительная защита от подбора по хешам.
Как я и написал, никто не мешает это делать, но ни от слива ни от последующего подбора это не спасает. Сливы, в основном, делаются не путём кражи/копирования физического носителя. Другой вектор атаки.
Есть разные методы - https://ru.wikipedia.org/wiki/Шифрование_базы_данных
Из перечисленных там все в той или иной мере выдают расшифрованные данные по условному SELECT'у. Кроме метода "Шифрование на уровне приложений". Но именно это и делает хеширование :). Зашифровать каждый хеш сверху дополнительно, конечно, можно, но это малоосмысленно, тут полезнее усиливать функцию кеширования.
vasilijmooduckovic
29.10.2023 18:33перелагаю тему для следующей статьи - написание собственного правила для hashcat чтобы брутить пресловутую керилицу, oneRuleToRuleThemAll.rule не канает по умолчанию (scriptKidieSadness.jpg))(
mapnik
Разве Solar Designer — это компания? Всегда считал, что это человек.