Менеджер паролей: статистика взлома мастер-паролей и стойкость шифрования

Это число стало отправной точкой публичного разговора о стойкости мастер-паролей в облачных менеджерах.

Универсальной статистики о доле взломанных мастер-паролей в открытых источниках нет. Обычно можно увидеть лишь косвенные показатели: повторное использование паролей, сообщения об утечках зашифрованных копий хранилищ и опубликованные сервисами параметры выработки ключа. Они помогают оценить риск, но не дают простого ответа на вопрос, сколько хранилищ удастся открыть злоумышленникам. Итог зависит от нескольких условий сразу: качества мастер-пароля, настроек шифрования, состава похищенных данных и ресурсов атакующего.

Архитектура клиентского шифрования и границы защиты

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

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

Шифрование с нулевым знанием уменьшает риск доступа со стороны оператора, но при похищении зашифрованного хранилища защита упирается в мастер-пароль и параметры его преобразования в ключ.

Есть и другая граница: не вся информация, связанная с аккаунтом, обязательно зашифрована так же, как содержимое хранилища. В обновлении от 1 марта 2023 года LastPass сообщила, что в похищенных резервных копиях отдельные поля, включая URL в описанных компанией случаях, могли оставаться незашифрованными. По заявлению компании, мастер-пароли пользователей в похищенные данные не входили. Это не позволяет автоматически заключить, что все прочие сведения были открыты: состав и защита данных зависят от поля и обстоятельств. Но сам принцип важен: слов «хранилище зашифровано» недостаточно, чтобы понять, какие именно данные окажутся недоступны при утечке.

AES-256, часто упоминаемый в описании менеджеров паролей, тоже не отвечает сам по себе на вопрос о безопасности. Это алгоритм шифрования, а не обещание, что ключ невозможно получить. Если ключ создан из легко угадываемой фразы и его можно проверять снова и снова на украденной копии, стойкость алгоритма не спасает слабое исходное место. И наоборот, сильный мастер-пароль не отменяет ошибок в обработке данных, уязвимостей клиента или компрометации устройства, на котором хранилище уже расшифровано.

NIST SP 800-63B-4 и длина мастер-пароля

NIST SP 800-63B-4 задаёт требования к паролям в определённом контексте цифровой аутентификации. В частности, для пароля как единственного фактора на уровне AAL1 документ устанавливает минимальную длину в 15 символов. Он также отвергает обязательные правила состава вроде требования непременно добавить заглавную букву, цифру и специальный знак, а также регулярную принудительную смену пароля. Такой подход связан с тем, что формальные правила нередко подталкивают пользователей к предсказуемым вариантам, а частая смена сама по себе не гарантирует более надёжную защиту.

Стандарт разрешает менеджеры паролей и автозаполнение. В его логике это инструменты, которые помогают создавать уникальные пароли и уменьшают зависимость от человеческой памяти. Для обычных аккаунтов это особенно полезно: если один сайт теряет базу, пароль от него не должен открывать почту или банковский сервис.

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

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

Ещё одна причина не превращать рекомендации в соревнование по спецсимволам: мастер-пароль приходится вводить и восстанавливать в реальных условиях. Если пользователь боится забыть его, он может записать пароль рядом с устройством, сохранить в браузере или повторить тот, который уже использует где-то ещё. Формально усложнённый, но плохо запоминаемый пароль способен создать новые риски. Надёжность здесь включает и способность пользователя безопасно хранить секрет.

Функции выработки ключа: PBKDF2 и Argon2id

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

PBKDF2 повторяет вычисления заданное число раз. Чем больше итераций, тем выше стоимость каждой попытки, хотя замедляется и законная разблокировка хранилища. В техническом документе Bitwarden за 2025 год указано значение по умолчанию 600 000 итераций PBKDF2 для новых аккаунтов. Там же описана возможность после создания аккаунта перейти на Argon2id. Эти параметры относятся к указанной конфигурации сервиса, а не ко всем менеджерам и не ко всем существующим аккаунтам.

LastPass сообщила о 100 100 итерациях PBKDF2 для мастер-паролей в описанном инциденте 2022 года. Сопоставление этих чисел полезно, но его нельзя читать как рейтинг безопасности двух продуктов: параметры меняются со временем, зависят от настройки аккаунта и не показывают, насколько удачно пользователь выбрал сам пароль.

Соль добавляется при вычислении ключа и помогает сделать результаты для разных пользователей различными, даже если они выбрали одинаковый мастер-пароль. Она не является секретом и не заменяет сам пароль. Если хранилище похищено, атакующий может знать соль и всё равно проверять кандидаты, однако она мешает заранее подготовить одну универсальную таблицу результатов для множества аккаунтов.

Argon2id устроен иначе, чем PBKDF2: он требует не только вычислений, но и памяти. Это ограничивает эффективность параллельного перебора на специализированном оборудовании, где особенно выгодно запускать много дешёвых проверок одновременно. Однако сам факт использования Argon2id не делает слабый пароль сильным. Если мастер-пароль часто встречается в утечках или легко угадывается, функция лишь увеличит цену атаки.

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

Инциденты облачных хранилищ: что показывают LastPass и Dashlane

Инцидент LastPass важен именно тем, что речь шла о резервных копиях хранилищ. После получения такой копии атакующему не обязательно поддерживать доступ к аккаунту или подбирать пароль через экран входа. Он может проверять догадки локально, сколько бы времени это ни заняло. Если пароль слабый, а параметры выработки ключа недостаточно замедляют вычисления, длительная атака может оказаться практически значимой.

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

В 2026 году, согласно сообщению TechCrunch, были скачаны зашифрованные хранилища примерно 20 клиентов Dashlane. Сам факт скачивания важен: если атакующий получил копии, он может пытаться подбирать мастер-пароли офлайн, вне обычных ограничений на вход в аккаунт. Но скачивание зашифрованных хранилищ само по себе не подтверждает, что данные удалось расшифровать или что мастер-пароли были взломаны. Это разные этапы, и сообщения об одном нельзя подменять выводом о другом.

Для LastPass и Dashlane полезно сохранять одно и то же различие: инцидент с зашифрованной копией создаёт возможность перебора, но не говорит автоматически о его успехе. Чтобы оценить последствия, нужно понимать, какие именно данные затронуты, были ли они зашифрованы и какие меры требуются от пользователя. Формулировка о том, что пароль не хранился на сервере, не отвечает на вопрос о возможной копии зашифрованного хранилища. А сообщение о шифровании не говорит, насколько дорого злоумышленнику проверять варианты мастер-пароля.

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

Человеческий фактор: повторное использование и брутфорс

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

Зато сам риск повторного использования хорошо понятен без попытки свести его к одной универсальной доле. Если один и тот же пароль защищает менеджер и обычный сайт, утечка с сайта даёт атакующему готовую догадку для главного секрета. Если пароли различаются лишь цифрой в конце, это тоже не полноценная независимость: похожие шаблоны легко проверять автоматически. Генератор паролей в менеджере решает эту проблему для записей внутри хранилища, но мастер-пароль пользователь выбирает отдельно, и здесь привычка к повторению может вернуться.

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

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

Надёжная практика складывается из нескольких решений:

1. Сделать мастер-пароль уникальным. Он не должен повторять пароль от почты, рабочего аккаунта или сайта, даже если те пароли давно не менялись.

2. Выбрать длину с запасом. Длинная случайная фраза обычно удобнее для памяти, чем короткая комбинация с искусственными заменами символов.

3. Проверить настройки выработки ключа. Для старого аккаунта стоит выяснить, какие параметры используются сейчас и доступен ли переход на более современную функцию.

4. Защитить устройства. Если устройство разблокировано, заражено вредоносной программой или оставлено без контроля, шифрование хранилища может уже не помочь.

5. Включить дополнительную защиту входа, где она доступна. Многофакторная аутентификация усложняет захват аккаунта через обычный вход, хотя сама по себе не остановит перебор уже похищенной копии хранилища.

6. Продумать восстановление доступа. Сильный мастер-пароль бесполезен, если единственный экземпляр секрета потерян и восстановить хранилище невозможно. Способ хранения резервной информации должен быть защищён не слабее самого аккаунта.

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

Что в итоге определяет стойкость

Когда спрашивают, насколько часто взламывают мастер-пароли, честный ответ обычно звучит менее эффектно, чем единый процент: сопоставимой публичной статистики нет. Есть отдельные инциденты и технические параметры, по которым можно оценить риск конкретного сценария. Случай LastPass показал, что похищенная зашифрованная копия остаётся целью для длительного офлайн-перебора. Сообщение о скачанных хранилищах Dashlane в 2026 году тоже указывает на такой сценарий, но не подтверждает расшифровку данных или взлом мастер-паролей.

AES-256 защищает данные при корректной реализации и надёжном ключе. PBKDF2 или Argon2id повышают цену каждой попытки подбора. Соль мешает использовать одни и те же заранее рассчитанные результаты против множества аккаунтов. А выбор пользователя определяет, начнёт ли атакующий с очевидного кандидата или столкнётся с длинной и непредсказуемой фразой. Ни один из этих элементов по отдельности не решает всю задачу.

Менеджер паролей ценен тем, что снимает необходимость придумывать и помнить десятки разных секретов. Но мастер-пароль остаётся исключением: это один из немногих ключей, который нельзя бездумно передать генератору и забыть. Его лучше сделать уникальным, достаточно длинным и таким, чтобы его можно было безопасно восстановить самому, но нельзя было угадать по следам в сети. Именно сочетание пользовательской привычки и технических параметров, а не громкое название алгоритма, определяет, насколько стойким окажется хранилище при реальной атаке.