# Почему Summer2026! ломается быстрее случайного набора: разбор hashcat
# Почему Summer2026! ломается быстрее случайного набора: разбор hashcat ----------------------------- Привет, подписчики! На связи DevGeek.IT ----------------------------- Знакомая картина: пароль Summer2026! проходит любую форму регистрации — заглавная буква, цифры, спецсимвол, нормальная длина. А потом падает первым, пока короткая случайная строка держится часами. Это не магия и не утечка. Просто hashcat умеет воспроизводить человеческие привычки, а привычка — это шаблон. ----------------------------- Разберём этот шаблон на пальцах. Заглавная первая буква, словарное слово, год, восклицательный знак в конце. Ровно это описывается правилом `c$2$0$2$6$!` — и проверяется за миллисекунды. Программа не «угадывает» твой пароль, она повторяет то, как думают миллионы людей. Случайная последовательность такой структуры не имеет, поэтому её приходится перебирать полным перебором. ----------------------------- Сервис не хранит пароль открытым текстом: при регистрации считается проверочное значение, при входе вычисление повторяется. Если база украдена, ограничения входа, CAPTCHA и задержки сайта уже не участвуют — подбор идёт локально. Хеширование отличается от шифрования: обратной операции с ключом нет, но слабый пароль можно угадать, просто сравнивая результаты вычислений. ----------------------------- **🛠 Фишка от DevGeek.IT:** Не угадывай формат по длине строки. `hashcat --identify hashes.txt` предложит варианты, но первый результат брать наугад нельзя. Прогони режим на контрольной записи с известным паролем — так ты отделишь ошибку подготовки от неудачного словаря. ----------------------------- Соль — случайное значение для каждой записи, хранится рядом с результатом и не скрывается. Она лишает атакующего одной заранее посчитанной таблицы для всей базы, но сама попытку не замедляет. За цену попытки отвечают алгоритм и параметры: у bcrypt cost задаёт сложность по экспоненте (с 10 на 12 — примерно вчетверо больше работы), у Argon2id важны память, проходы и параллелизм. Названия алгоритма без параметров для оценки стойкости недостаточно. ----------------------------- Обычные MD5, SHA-1 и даже SHA-256 слишком быстры для хранения человеческих паролей. Даже криптографически стойкий SHA-256 без парольной схемы позволяет проверять массу догадок. Для защиты нужны функции, намеренно расходующие время, а современные — ещё и память. Утверждение «миллион записей всегда подбирается ровно в миллион раз дольше» некорректно: время зависит от числа уникальных солей, параметров и железа. ----------------------------- Вот словарный режим с правилами на учебном примере (Bash, Linux): ```bash printf '%s' 'Orbit2026!' | sha256sum | cut -d ' ' -f 1 > hashes.txt printf '%s\n' orbit comet > words.txt printf '%s\n' 'c$2$0$2$6$!' > demo.rule hashcat -m 1400 -a 0 hashes.txt words.txt -r demo.rule --session demo --potfile-path demo.potfile hashcat -m 1400 hashes.txt --show --potfile-path demo.potfile ``` Правило `c` делает первую букву заглавной, `$2$0$2$6$!` дописывает 2026! в конец. Из слова orbit получается нужный кандидат. `-m 1400` — это SHA-256, выбран для наглядности; хранить реальные пароли так нельзя. ----------------------------- Маска описывает допустимые символы по позициям и полезна, когда структура известна. `?l` — 26 строчных латинских, `?u` — 26 заглавных, `?d` — цифры, `?s` — спецсимволы ASCII, `?a` — все 95 печатных. `?b` — любой байт, а не произвольный Unicode. Маска `?u?l?l?l?l?d?d?d?d` даёт около 118 миллиардов комбинаций: при миллионе проверок в секунду это порядка 33 часов, при тысяче — почти 3,8 года. Без `--increment` маска фиксирует длину. ----------------------------- Комбинации словаря и маски (`-a 6`, `-a 7`), два списка (`-a 1`), несколько файлов правил — всё это резко раздувает объём. Два набора правил hashcat комбинирует между собой, поэтому очередной большой файл может увеличить длительность сильнее, чем добавить полезных кандидатов. Начинай с малого и добавляй преобразования под конк