Оценка надёжности паролей, сгенерированных большими языковыми моделями
Исследователи проанализировали, насколько действительно безопасны пароли, которые предлагают современные большие языковые модели и AI-ассистенты. В эксперименте использовались Claude, ChatGPT и Gemini. Каждой системе задавали одинаковую задачу: сгенерировать "надёжный 16-символьный пароль".
На первый взгляд всё выглядело безупречно. Полученные пароли содержали:
- заглавные и строчные буквы,
- цифры,
- спецсимволы.
Стандартные утилиты проверки сложности паролей оценивали такие варианты как "сильные", часто - с прогнозом взлома "через века". Однако детальный анализ показал, что реальная стойкость этих паролей значительно ниже, чем кажется.
Иллюзия безопасности: низкая энтропия при "красивом" виде
Ключевая проблема - в энтропии, то есть в реальной непредсказуемости пароля. По расчётам исследователей, у паролей, сгенерированных большими языковыми моделями, энтропия составляет всего 20-27 бит. Это означает, что перебор такого пароля при современных возможностях может занять от нескольких секунд до нескольких часов, а не сотни лет, как утверждают типичные "оценщики сложности".
Причина в том, что модели не "бросают виртуальные кости" для каждого символа, а генерируют текст по вероятностному шаблону токенов. В результате:
- пароли выглядят разнообразно,
- но следуют повторяющимся паттернам,
- и при многократных запросах наблюдается устойчивая закономерность.
Шаблоны в паролях разных моделей
Анализ сгенерированных паролей показал выраженную типизацию:
Claude Opus 4.6
- Из 50 сгенерированных паролей 18 полностью совпали с уже встречавшимися - то есть более трети были просто дубликатами.
- Все пароли начинались с буквы (чаще всего "G").
- За первой буквой почти всегда следовала цифра, в основном "7".
- Во всех паролях стабильно встречались одни и те же символы: "L", "9", "m", "2", "$" и "#".
GPT-5.2
- Почти каждый пароль начинался с буквы "v".
- В половине случаев за "v" шла буква "Q".
- Далее использовался повторяющийся набор символов из сильно ограниченного множества.
Gemini 3
- Почти половина паролей начиналась с "K" или "k".
- Затем часто шли символы "#", "P" или "9".
- Набор реально используемых символов был заметно урезан, что сильно снижало вариативность.
Попытки повысить "температуру" - то есть сделать генерацию более случайной - не дали ощутимого роста качества паролей. Шаблонность оставалась, а значит, сохранялась и предсказуемость.
Почему так происходит: природа языковых моделей
Большие языковые модели устроены так, что вместо истинной случайности они:
- предсказывают следующий токен (фрагмент текста) на основе вероятности,
- тяготеют к "типичным" и "правдоподобным" сочетаниям,
- стараются выдавать результат, похожий на человеческий.
Для текста это хорошо: фразы получаются плавными и логичными.
Для паролей - плохо: модель стремится создать что‑то "похожее на сложный пароль", а не действительно случайную строку максимальной энтропии.
В итоге получаются пароли, которые:
- формально удовлетворяют требованиям сложных политик (длина, разные типы символов),
- но укладываются в довольно узкий набор шаблонов,
- могут быть подвержены целевому взлому с учётом статистики генерации конкретной модели.
Опасный момент: такие пароли реально используются
Исследователи отмечают, что подобные предсказуемые пароли:
- уже используются реальными пользователями - те просто копируют то, что им предложил AI-ассистент;
- нередко попадают в код через системы автодополнения и подсказок, в том числе в конфигурации, тестовые окружения, примеры.
Это значит, что проблема не теоретическая, а вполне практическая: шаблонные пароли могут массово "утекать" в инфраструктуру и пользовательские аккаунты.
Как ведут себя AI-ассистенты разработчиков
Отдельно проанализировали, как именно ассистенты для программистов генерируют пароли и секреты. Ситуация оказалась неоднородной и сильно зависящей от того, как прописаны подсказки и логика самих инструментов.
Claude Code c Opus 4.6 и Gemini-CLI с Auto Gemini 3
- При запросе "сформировать надёжный пароль" эти ассистенты не полагались на саму языковую модель.
- Вместо этого они вызывали внешнюю команду `openssl rand`, которая создаёт криптографически стойкие случайные строки.
- Примечательный нюанс: в случае Gemini-CLI с Auto Gemini 3:
- на запрос "сгенерируй пароль" использовался `openssl rand`,
- но на запрос "предложи пароль" - уже подключалась сама AI-модель, и результат становился предсказуемым.
Codex c GPT-5.3-Code
- Иногда поступал корректно и запускал внешнюю утилиту для генерации безопасного пароля.
- Но временами вместо этого генерировал пароль своими силами через языковую модель - и такой пароль оказывался предсказуемым.
Claude Code c Opus 4.5
- В большинстве случаев самостоятельно создавал "красивые", но предсказуемые пароли.
- Использования стороннего криптографического генератора при этом не наблюдалось.
Браузер ChatGPT Atlas
- При регистрации на сайте, когда пользователь просил "придумать пароль", браузер формировал ненадёжный пароль средствами AI-модели, а не с помощью встроенного криптоустойчивого генератора.
Вывод однозначен: качество и надёжность пароля зависят не только от самой модели, но и от того, как именно разработчики интегрировали её в продукт и какие механизмы предусмотрели для генерации секретов.
Почему стандартные "оценщики сложности" ошибаются
Большинство популярных утилит для оценки состояния пароля работают по евристикам:
- проверяют длину,
- считают наличие разных типов символов,
- оценивают наличие словарных слов,
- примерно прикидывают объём пространства перебора.
Но они не учитывают:
- статистику поведения конкретной языковой модели,
- повторяемость шаблонов при массовой генерации,
- реальные распределения символов и токенов, характерные для AI-сгенерированных паролей.
В итоге то, что программа считает "стоходлетней защитой от брутфорса", на практике может быть взломано за часы, если атакующий знает, как именно модель генерирует такие пароли и на основе каких паттернов.
Основной риск: массовая предсказуемость
Классический слабый пароль вроде "123456" плох тем, что им пользуются миллионы людей. В случае AI-моделей проблема иная, но по сути похожая:
- модель систематически предлагает ограниченный набор паттернов,
- многие пользователи доверяют ей и используют предложенное,
- количество реальных комбинаций, встречающихся "в поле", оказывается небольшим.
То есть атакующему достаточно:
- изучить типичные образцы паролей для популярной модели и её версии,
- построить генератор, воспроизводящий те же паттерны,
- сократить пространство перебора от астрономических значений до вполне реальных объёмов.
Что делать пользователю: практические рекомендации
Чтобы не попасть в ловушку "красивого, но предсказуемого" пароля, разумно придерживаться нескольких правил:
1. Не использовать пароли, напрямую сгенерированные языковой моделью
Особенно если это простая текстовая команда вида "придумай надёжный пароль". Такой результат нельзя считать криптографически случайным.
2. Полагаться на встроенные генераторы паролей в менеджерах и браузерах
Большинство современных менеджеров паролей и браузеров применяют криптостойкие генераторы случайных чисел и не строятся на языковых моделях. Их пароли гораздо менее предсказуемы.
3. Избегать "красиво читающихся" паролей
Случайный пароль по-настоящему часто выглядит "уродливо", плохо запоминается и вообще не напоминает осмысленный текст. Если пароль выглядит как удачно собранная "красота" с понятным шаблоном - это повод насторожиться.
4. Не генерировать пароли вручную по "своим" шаблонам
Люди склонны к предсказуемым паттернам не меньше моделей: замены типа "a" → "@", "s" → "$" давно учитываются в атаках. При отсутствии менеджера паролей лучше использовать длинные фразы (пасспфразы) с большим числом слов, а не "умные" комбинации.
5. Использовать разные пароли для разных сервисов и включать двухфакторную аутентификацию
Даже лучший пароль не заменит полноценной защиты. Наличие второго фактора резко снижает пользу от украденного или подобранного пароля.
Что важно учесть разработчикам и интеграторам AI
Для разработчиков, строящих продукты поверх языковых моделей, выводы ещё жёстче:
- Нельзя поручать LLM генерацию секретов, ключей и паролей напрямую.
Это противоречит базовой модели их работы: предсказуемость - их природа.
- Нужно жёстко разделять:
- генерацию кода и подсказок (LLM),
- и генерацию секретов (криптоустойчивые RNG, внешние утилиты, стандартные библиотеки языка).
- Формулировка промпта критична.
Именно из-за разницы между запросами "сгенерируй пароль" и "предложи пароль" некоторые ассистенты переходят от безопасного внешнего генератора к небезопасной генерации через модель.
- Следует явно проверять, как ассистент ведёт себя в разных сценариях.
Нужны тесты, которые проверяют: в ответ на любые вариации запросов вроде "пароль", "секрет", "ключ", "токен" ассистент обязан использовать криптостойкий генератор, а не LLM.
- Важно документировать ограничения.
Пользователь должен понимать, что ответы модели - это текст, а не криптографический механизм, и не использовать их как источник непредсказуемых секретов.
Можно ли сделать LLM безопасным генератором паролей?
Теоретически можно попытаться:
- жёстко ограничить алфавит и длину,
- добавить внешний источник случайности,
- использовать модель только как интерфейс для вызова криптобезопасных библиотек.
Но в таком сценарии роль LLM - не генерировать пароль, а:
- объяснить пользователю принципы,
- оформить подсказку в удобном виде,
- вызвать соответствующую функцию окружения.
То есть безопасный подход - это когда именно система/среда генерирует пароль, а AI-модель служит лишь голосовым или текстовым интерфейсом к правильным инструментам.
К чему всё идёт
По мере того как ассистенты на базе LLM встраиваются в операционные системы, IDE, браузеры и прочие массовые продукты, риск расползания предсказуемых паролей будет только расти, если разработчики не будут учитывать ограничения этих моделей.
Главный вывод исследования можно сформулировать так:
- Пароль, предложенный большой языковой моделью, может выглядеть сложным,
но при этом быть статистически предсказуемым и иметь низкую энтропию.
Использовать такие пароли как основной способ защиты аккаунтов и инфраструктуры нельзя. Для безопасной генерации секретов всё так же нужны проверенные криптографические механизмы, а AI-инструменты должны быть лишь надстройкой над ними, а не их заменой.
