Вступление
Оговорочка по Фрейду в самом начале статьи — да, я использовал искусственный интелект (а именно модель Opus 4.8, Effort Max) и да, в каком‑то смысле я переосмыслил работы других исследователей этого сегмента. Свою работу я воспринимаю исключительно как учебный проект, но именно потому, что я считаю его важным для области, хочу поделиться своими мыслями в формате истории о пройденном пути.
И так, что мы имеем и для чего же собственно эта статья? Когда человеку ставят задачу в духе «Придумай пароль» — он берет и генерирует самостоятельно некую псевдослучайную последовательность, что в будущем именуется паролем (или с помощью генераторов паролей, которые встроены во все популярные браузеры, или с помощью установленных утилит). Казалось бы, можно и так понять, что самые часто используемые слова в духе «мама», «папа», «пароль» и другие — вполне объяснимы. Это то, что нас в большинстве своем объединяет, а потому может намного чаще встречаться в паролях. Не все люди хотят заморачиваться и отказываться от простых и понятных аналогиях. На примере старшего поколения моей семьи (бабуле) могу хоть сколько раз подтвердить, что ее излюбленный пароль был именем дочери и годом ее рождения.
А ведь в таких псевдо случайных генерациях можно встретить «проблему раскладки» (то, что проанализировано было в русском сегменте только в 2025 году следующими лицами: Леа Мюллер, Аушриус Юозапавичюс, Владимир Охримчук, Стефан Зюттерлин в работе «Поиск в словаре с использованием преобразованных русских слов на клавиатуре QWERTY», P. S. я мог допустить ошибки в переводе информации, за что прошу прощения). Если кратко, то это создает некую «маску», зная которую можно облегчить взлом. Подобные словари встречаются в открытом доступе, и еще чаще встречаются в недоброжелательном сообществе за разные суммы денег.
Если интересно узнать сразу какой‑то результат
Забегая вперед, могу сказать, что полученные мною данные нельзя назвать полноценно достоверными. Причин на то достаточно — данные 2022 года, взяты с github, потенциально сгенерированы алгоритмами. Больше достоверности можно получить только замутив коллаборацию с компаниями в духе Kaspersky или другими, кто может реализовать сбор анонимной статистики продукта массово и безопасно.
Что я изучил (грубо говоря: что у меня есть на старте)
Перебор по порядку при наличии 8 и более символов — не сложное дело, но даже простые правила установки паролей на сайте не одобряют пароль «aaaaaaaa». Политика паролей изменяется каждый раз, когда случается реальный инцидент и масштабируется в зависимости от существующих технологий. Поэтому не секрет, что слепой перебор имел место быть когда‑то и имеет место быть сейчас, но намного лучше и приятнее — оптимизировать работу машины алгоритмами и правилами.
Например, существуют следующие понятия:
Словарь в совокупности с правилами. Самый простой пример, берем некий список самых часто используемых слов — это наш словарь. И прописываем к нему правила: прибавляй цифры в конце, начале, середине, меняй регистры, используй общепринятые и читаемые замены в духе O = 0. Эта предсказуемость в людях до сих пор живет.
PCFG (Probabilistic Context‑Free Grammar или вероятностная контекстно‑свободная грамматика). Пароль описывают здесь как некую структуру. На примере: есть пароль «
password123!» — здесь у нас 8 букв, 3 цифры, 1 спец.символ. Модель анализирует, какие структуры встречаются чаще, и выдает некий сортированный список по убыванию вероятности. Шанс подобрать пароль таким способом, конечно, больше.Марковские модели (n‑граммы). Попытки предсказывать следующий символ на основе предыдущего. Мы заранее не выстраиваем структуры, а стараемся учитывать контекст — сейчас это широко известно по LLM‑моделям.
То, что я знаю, но не закладывал при проектировании проекта это следующий уровень после описанных — RNN, PassGAN (нейросетевые генераторы). Все данные по этим способам есть в открытых источниках, в т.ч. на Habr, поэтому можете ознакомиться в свободное время или прерваться уже сейчас.
Теперь представляю вам свою новинку: TFM
Это название посчиталось мне интересным, да и не было каких‑то супер идей. Такие варианты как «зеленая маска», «aodwaowdw2oa2» и прочие — все показались мне менее достойными.
Собственно представляю вам свое творение с громким именем «TFM, Transform‑Factored Model». Если убрать пафос, то должно получиться что‑то такое — пароль — это совокупность некоего ядра (например, слова из словаря) и дополнительно стопка обратимых «масок».
Маски у меня взяты следующие:
Раскладка («
пароль» → «gfhjkm», работает в обе стороны);Транслитерация («
parol» → “пароль”, работает также в обе стороны);Регистр («
пароль» → «Пароль», «пАроль», «паРоль» и прочее, логика думаю ясна);Суффиксы («
пароль» → «пароль2026»)
TFM (буду сокращенно называть его так) пытается разложить пароль на множители, как число раскладывается на простые. Берём Gfhjkm2020, аккуратно снимаем маски по очереди — заглавную, +2020, раскладку — и смотрим: осталось пароль? Есть такое слово в русском словаре? Если да — пароль «объяснён дёшево»: он не случайный, он переодетое словарное слово.
Раскладка, транслит — давно известные комбинации, как и регистр и суффиксы. Мой метод просто собирает их воедино и делает подобные расчеты системными. Конкретные результаты прогона будут ниже.
Метрика («TL»)
Если у нас есть какой‑то способ или алгоритм, нам нужно найти способ выявления итогов (результатов). Собственно на основании метода названа метрика — Transform Leakage или «утечка через маскировку». Другими словами мы ищем какая доля паролей известна после снятия масок и оказывается словарным словом?
Представьте карнавал в масках. Leakage — доля гостей, чью личность вы узнаете, просто зная стандартный набор масок из ближайших магазинов приколов и интересы ваших знакомых/друзей.
Теперь про то, где я искал пароли, стараясь не нарушить закон
Да, я прекрасно понимаю, что есть много «открытых баз данных» из разных источников. Но вот источники, что нельзя назвать хоть сколько‑то достоверными нам не подходят. Как минимум, это обработка потенциально персональных данных, и скорее всего не обезличенных. Поэтому после долгих поисков я понял следующие очевидные вещи:
Ни одна компания РФ не готова делиться секретами/словарями и другими данными по паролям. За границей дела обстоят чуть‑чуть лучше — подобные исследования есть, вот только тут два препятствия — это другой язык (например, английский), и данные актуальны на ~2022 год (это я, заглядывая в будущее, к сожалению, не обошел).
У нас попросту нет открытых аналитик на этот счет. Поэтому если кто‑то готов их создать — было бы замечательно. Формирование общества обмена групповыми политиками паролей, требований к ним, типам учетных записей — раз в какое‑то время было бы эффективно.
Поэтому спасибо большое проекту rockrus2022 (взято с github). Сгенерированный/расширенный список кандидатов, обезличенных, около 120 миллионов строк, ориентир на русскоязычный сегмент. Доминирующая структура у меня получилась следующая: U1 l1 d8 (заглавная + буква + 8 цифр). Таких я нашел с самого начала ~13,2 млн. Нечто подобное даже приблизительно не характеризует россиян (хотелось бы верить), поэтому признаем это артефактом генерации списка. Поведенческие выводы в таком случаем делаем по «голове» — частотным и реалистичным записям, которые ближе к реальным паролям.
О граблях (да, да, тот самый раздел, который могли многие ждать)
Я нашел «то, чего нет». Именно так как вы подумали. Первые прогоны находили десятки «устойчивых паттернов». Пока я не понял, что большинство из них — шум. Если долго обрабатывать огромные массивы данных, безусловно можно получить закономерность. Это классика, которую я не предусмотрел в самом начале.
«0,26%» против «5,29%». Первый настоящий замер TL дал показатель 0,26%. Оказалось, что в хвосте было слишком много мусора, если его так можно назвать. Я чуть‑чуть исправил код и считывание БД, и все значительно улучшилось.
SQLite и OneDrive. Это типичная ошибка невнимательности. Синхронизация папки с OneDrive, на который у меня конечно же не было подписки создало ситуацию под названием
database is locked, битые файлы и шторм. 6 часов обработки данных впустую.
Это, пожалуй, самые «нормальные» ошибки с которыми я столкнулся. Конечно, были и косяки в духе попыток удалить части БД во время использования.
Конвейер против галлюцинаций
Еще одним не мало важным для меня открытием стало то, что любые модели подвержены галлюцинациям. Частично это проявляется в ошибке № 1, которую я указал выше. Их условно можно разделить на следующее:
Находки. Ищем паттерны, находим тысячи, десятки тысяч — во всех что‑то есть.
Репликации. Ищем повторение закономерностей. Тут реализовано было по crc32 (проверка передачи, хранения данных).
FDR (поправка Бенджамини‑Хохберга, 1995). Когда проверяешь тысячу гипотез сразу, часть «значимых» результатов будет ложной просто по теории вероятностей. FDR математически ограничивает долю таких ложных срабатываний. Без этого «p < 0.05» на тысяче проверок — самообман.
Опора. Паттерн должен опираться на «живые пароли» (перепроверка, так как. PCFG, Марков, TFM — все варианты могут выдать структуры, которые по итогу не имеют реальных записей)
Вот такой результат у меня получился: из 954 кандидатов 872 приняты, 82 отсеяны как галлюцинации.
Результаты
Весь проект у меня уложился примерно в ~40 часов с момента идеи до реализации. Анализ данных (несколько итераций, в т.ч. для перепроверок и ошибок) занял у меня около 10 часов суммарно. 6 часов первый прогон, дальше наращивал мощности и попробовал подключить многопоточную обработку — получилось.
Transform Leakage (TL) = 5,29% = раскладка 0,98% + транслитерация 4,31%
872 подтвержденных паттерна (82 отсеяно)
буквы ~50%, цифры ~46%, заглавные ~3,6%, спец.символы ~0,5%
К слову, в работе Мюллер по раскладке зафиксировано значение в 0,96% точных совпадений (и 6% частичных) против моих 0,98%.
По уникальности TFM: улучшение показывает 7 против 372, это около 2% итогового прироста. При увеличении силы исходного словаря для анализа не исключаю, что значение может быть изменено как в лучшую, так и в худшую сторону. Это вполне честный и заслуженный результат соответствующего учебного проекта — повторить в попытках превзойти.
Исходя из имеющихся данных я могу предположить, что:
Результаты не сильно помогут взломщикам по типу hydra и других (что логично, но мало ли). Самое разумное применение — сузить круг анализа людей, объединенных общим делом, интересом (отделом) и использовать как оценщик стойкости при регистрации. Здесь вспоминаю проект с github zxcvbn, знает про раскладку, транслит и укажет на попытки обмануть систему.
Все люди разные — искать «паттерн» у каждого можно рассматривать как ошибку. В данном случае это воспринималось как распределение по толпе, «попадает ли пароль в слабозащищенный класс».
Источники
— Weir et al. (2009). Password Cracking Using Probabilistic Context‑Free Grammars. IEEE S&P.
— Narayanan, Shmatikov (2005). Fast Dictionary Attacks… ACM CCS.
— Melicher et al. (2016). Modeling Password Guessability Using Neural Networks. USENIX Security.
— Benjamini, Hochberg (1995). Controlling the False Discovery Rate. JRSS‑B.
— Wheeler (2016). zxcvbn: Low‑Budget Password Strength Estimation. USENIX Security.
— Müller, Juozapavicius, Okhrimchuk, Sütterlin (2025). Dictionary Attack with Transformed Russian Words using QWERTY Keyboard Layout. Baltic J. Modern Computing 13(4), 919–932.
— DLBI — ежегодная статистика паролей из утечек (для сравнения масштабов).
