Оценка безопасности генерации, хранения и автозаполнения паролей в браузерных менеджерах паролей

1. Введение

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

2. Методология и область исследования

Оценка охватила тринадцать менеджеров паролей, включая пять браузерных расширений (например, LastPass, 1Password), шесть встроенных браузерных менеджеров (например, Chrome, Firefox) и два настольных клиента для сравнения. Методология включала:

• Генерацию и анализ корпуса из 147 миллионов паролей на предмет случайности и стойкости.
• Воспроизведение и расширение предыдущих оценок безопасности хранения паролей.
• Тестирование механизмов автозаполнения на уязвимости, такие как кликджекинг и XSS.
• Оценку настроек безопасности по умолчанию и практик шифрования.

3. Анализ генерации паролей

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

4. Безопасность хранения паролей

Хотя по сравнению с оценками пятилетней давности были отмечены улучшения, серьёзные проблемы сохраняются.

5. Уязвимости механизма автозаполнения

Функция автозаполнения, созданная для удобства, представляет собой значительную поверхность для атаки.

6. Результаты и сравнительный анализ

Ключевой вывод: Ситуация улучшилась по сравнению с предыдущими исследованиями (например, Li et al., 2014; Silver et al., 2013), но фундаментальные недостатки безопасности сохраняются у нескольких поставщиков. Ни один менеджер паролей не был безупречным на всех трёх оценённых этапах (генерация, хранение, автозаполнение). Как встроенные браузерные менеджеры, так и специализированные расширения демонстрировали различные паттерны уязвимостей.

7. Рекомендации и направления развития

Статья завершается практическими рекомендациями:

• Для пользователей: Избегайте менеджеров паролей с известными недостатками генерации или небезопасными настройками автозаполнения по умолчанию. Предпочитайте менеджеры, которые позволяют детальный контроль над поведением автозаполнения.
• Для разработчиков: Реализуйте криптографически стойкие генераторы случайных чисел (CSPRNG) для генерации паролей. Шифруйте все метаданные. Внедряйте строгую проверку источника и механизмы согласия пользователя для автозаполнения (например, требование клика на элементе, не подверженном подмене интерфейса).
• Для исследователей: Изучите интеграцию формальных методов для верификации логики автозаполнения и применение машинного обучения для обнаружения аномальных запросов автозаполнения, указывающих на атаку.

8. Оригинальный анализ и комментарии экспертов

Ключевая мысль: Исследование Оэша и Руоти даёт отрезвляющую проверку реальности: инструменты безопасности, которым мы доверяем консолидацию наших цифровых ключей, сами построены на тревожно шатком фундаменте. Спустя пять лет после раскрытия серьёзных недостатков прогресс в отрасли, в лучшем случае, незначителен и не решает системные проблемы во всех трёх основных столпах — генерации, хранении и автозаполнении. Это не просто отчёт об ошибках; это обвинение в самоуспокоенности в критически важной сфере безопасности.

Логическая последовательность: Сила статьи заключается в её целостном подходе к жизненному циклу. Она верно определяет, что цепь прочна настолько, насколько прочно её самое слабое звено. Обнаружение неслучайности в генерации ($P(символ) \neq \frac{1}{N}$) фундаментально подрывает всю предпосылку ещё до рассмотрения хранения или автозаполнения. Воспроизведение прошлых тестов хранения/автозаполнения затем показывает закономерность: хотя поверхностные уязвимости могут быть исправлены, архитектурные недостатки (такие как незашифрованные метаданные или неразборчивое автозаполнение) сохраняются. Эта логическая прогрессия от ошибочного создания к небезопасной обработке и рискованному развёртыванию рисует полную и обличающую картину.

Сильные стороны и недостатки: Основная сила исследования — его масштабный, основанный на данных подход к генерации паролей, первый в литературе. Корпус из 147 миллионов паролей предоставляет неопровержимые статистические доказательства алгоритмической слабости, выходя за рамки теоретических опасений. Однако в анализе есть слепое пятно: он в основном рассматривает менеджеры паролей как изолированные клиенты. Современная реальность — это облачная синхронизация и мобильные приложения. Как отмечено в материалах IEEE Symposium on Security and Privacy о моделях облачной безопасности, поверхность для атаки расширяется до протоколов синхронизации, серверных API и интеграции с мобильными ОС, что данное исследование не оценивает. Кроме того, хотя в нём упоминаются «небезопасные настройки по умолчанию», оно не количественно оценивает уровень принятия пользователями безопасных настроек — критический фактор реального риска, как постоянно показывают исследования удобства использования с конференции USENIX SOUPS, что большинство пользователей никогда не меняют настройки по умолчанию.

Практические выводы: Для команд корпоративной безопасности это исследование обязывает перейти от общих рекомендаций «используйте менеджер паролей» к рекомендациям, специфичным для конкретного поставщика и конфигурации. Менеджеры со слабыми генераторами должны быть внесены в чёрный список. Контрольные списки закупок теперь должны включать проверку использования CSPRNG и шифрования метаданных. Для разработчиков путь вперёд ясен: принять принцип «нулевого доверия» для автозаполнения, требуя явного, контекстно-зависимого согласия пользователя для каждого действия заполнения, аналогично моделям разрешений, пропагандируемым Консорциумом Всемирной паутины (W3C) для мощных веб-API. Будущее заключается не в попытке идеально защитить излишне разрешительное автозаполнение, а в проектировании минимально разрешительного, контролируемого пользователем. Неспособность отрасли самоисправиться за пять лет предполагает, что может потребоваться вмешательство регулирующих органов или органов по стандартизации (например, NIST или FIDO Alliance) для обеспечения базовых требований безопасности для этих хранителей нашей цифровой идентичности.

9. Технические детали и результаты экспериментов

Анализ генерации паролей: Энтропия $H$ сгенерированного пароля длиной $L$ из набора символов $C$ в идеале составляет $H = L \cdot \log_2(|C|)$ бит. В исследовании были обнаружены случаи, когда эффективная энтропия была ниже из-за смещённого выбора символов. Например, если генератор предназначен для использования набора из 94 символов, но определённые символы появлялись с вероятностью $p \ll \frac{1}{94}$, фактическая энтропия снижается: $H_{факт} = -\sum_{i=1}^{94} p_i \log_2(p_i)$ на символ, где $\sum p_i = 1$.

Описание экспериментального графика: Ключевой график в исследовании отображал бы кумулятивную долю взломанных паролей в зависимости от количества попыток подбора (логарифмическая шкала) для сгенерированных паролей разной длины (например, 8, 12, 16 символов). Кривая для паролей короче 10 символов показала бы крутой подъём, указывая на быстрое компрометирование в симуляциях онлайн-атак (например, 1000 попыток). Кривая для паролей короче 18 символов показала бы значительную долю взломанных после $10^{10}$ до $10^{12}$ офлайн-попыток, что помещает их в сферу возможностей целеустремлённых злоумышленников с современным оборудованием, как показывают тесты инструментов вроде Hashcat и радужных таблиц.

10. Фреймворк анализа и примеры из практики

Фреймворк для оценки безопасности менеджера паролей:

1. Целостность генерации: Статистически тестировать выходные данные на случайность (например, тесты NIST STS, Dieharder) и вычислять эффективную энтропию. Проверять, соответствуют ли настройки минимальной длины по умолчанию текущим рекомендациям NIST (>= 12 символов).
2. Безопасность хранения: Проверять локальное хранилище (например, IndexedDB браузера, файлы SQLite) и сетевой трафик на наличие зашифрованных и открытых данных. Аудит библиотеки шифрования и функции формирования ключа (например, используется ли PBKDF2 с достаточным количеством итераций или Argon2?).
3. Положение безопасности автозаполнения: Определить механизм запуска автозаполнения. Тестировать на подмену интерфейса, создавая перекрывающиеся iframe. Тестировать логику сопоставления источника, развернув сайты с похожими доменными именами (например, `example.com` против `example.com.evil.net`). Проверить, требует ли автозаполнение жеста пользователя на непредсказуемом элементе страницы.

Пример из практики — уязвимость кликджекинга: Рассмотрим Менеджер X, который показывает кнопку автозаполнения над формой входа. Злоумышленник создаёт вредоносную страницу с невидимым iframe, загружающим `bank.com`. Iframe позиционируется так, что кнопка автозаполнения Менеджера X появляется над скрытой кнопкой «отправить-злоумышленнику» на вредоносной странице. Пользователь нажимает для автозаполнения, но вместо этого нажимает кнопку злоумышленника, отправляя учётные данные `bank.com` на сервер злоумышленника. Это демонстрирует сбой в привязке событий клика и проверке источника менеджера.

11. Будущее применение и перспективы исследований

Результаты открывают несколько направлений для будущей работы:

• Генерация и хранение с аппаратной поддержкой: Интеграция с доверенными платформенными модулями (TPM) или безопасными анклавами (например, Secure Element от Apple) для генерации случайных начальных значений и хранения ключей шифрования, выводя секреты из чисто программной среды.
• Контекстно-зависимое, основанное на риске автозаполнение: Использование машинного обучения для анализа контекста страницы (структура DOM, детали сертификата, репутация сайта) для оценки риска автозаполнения. Контекст с высоким риском может потребовать дополнительной аутентификации (биометрической) или полностью блокировать автозаполнение.
• Стандартизированные API безопасности: Разработка стандартизированного браузерного API с разрешениями для менеджеров паролей (например, преемник API `chrome.loginState`), который обеспечивает безопасный, изолированный доступ к учётным данным с чёткими запросами согласия пользователя, уменьшая поверхность для атаки от произвольного внедрения в DOM.
• Готовность к постквантовой криптографии: Исследование перехода шифрования менеджеров паролей на алгоритмы, устойчивые к атакам квантовых компьютеров, поскольку зашифрованное хранилище — это долгоживущий актив, чрезвычайно привлекательный для противников, применяющих тактику «собрать сейчас — расшифровать позже».
• Децентрализованные и модели самохранения: Изучение использования децентрализованных протоколов идентификации (например, на основе W3C Verifiable Credentials) для снижения зависимости от центрального хранилища, распределения риска и предоставления пользователям большего контроля.

12. Список литературы

1. Oesch, S., & Ruoti, S. (2020). That Was Then, This Is Now: A Security Evaluation of Password Generation, Storage, and Autofill in Browser-Based Password Managers. USENIX Security Symposium.
2. Li, Z., He, W., Akhawe, D., & Song, D. (2014). The Emperor's New Password Manager: Security Analysis of Web-based Password Managers. IEEE Symposium on Security and Privacy (SP).
3. Silver, D., Jana, S., Boneh, D., Chen, E., & Jackson, C. (2013). Password Managers: Attacks and Defenses. USENIX Security Symposium.
4. National Institute of Standards and Technology (NIST). (2017). Digital Identity Guidelines (SP 800-63B).
5. Stock, B., & Johns, M. (2013). Protecting the Intranet Against "JavaScript Malware" and Related Attacks. International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA).
6. Herley, C. (2009). So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. Proceedings of the New Security Paradigms Workshop (NSPW).
7. World Wide Web Consortium (W3C). (2021). Permissions Policy. https://www.w3.org/TR/permissions-policy-1/
8. FIDO Alliance. (2022). FIDO2: WebAuthn & CTAP. https://fidoalliance.org/fido2/