Аутентификация на основе паролей остается доминирующим методом для веб-аутентификации, несмотря на её хорошо задокументированные проблемы безопасности. Пользователи сталкиваются с когнитивной нагрузкой при управлении множеством сложных паролей, что приводит к их повторному использованию и созданию слабых паролей. Менеджеры паролей обещают решить эти проблемы, генерируя, храня и автоматически заполняя пароли. Однако их безопасность ставилась под сомнение в предыдущих исследованиях. В данной статье представлена обновленная, комплексная оценка безопасности тринадцати популярных браузерных менеджеров паролей, исследующая полный жизненный цикл: генерацию, хранение и автозаполнение.
Мы оценили тринадцать менеджеров паролей, включая пять браузерных расширений (например, LastPass, Dashlane), шесть встроенных в браузер менеджеров (например, Chrome, Firefox) и два настольных клиента для сравнения. Методология оценки охватывала три ключевых этапа: анализ случайности 147 миллионов сгенерированных паролей, оценку безопасности хранения (шифрование, обработка метаданных, настройки по умолчанию) и тестирование уязвимостей автозаполнения к таким атакам, как кликджекинг и XSS.
В этом разделе подробно описывается первое крупномасштабное исследование алгоритмов генерации паролей в менеджерах паролей.
Мы использовали статистические тесты на случайность, включая частотный анализ, расчет энтропии и тесты на равномерное распределение по заданным наборам символов (заглавные буквы, строчные буквы, цифры, специальные символы).
В нескольких менеджерах было обнаружено неслучайное распределение символов. Например, в некоторых наблюдалась предвзятость к определенным позициям или наборам символов, что снижало эффективную энтропию генерируемых паролей ниже теоретических ожиданий.
Важным открытием стало то, что часть сгенерированных паролей — особенно короче 10 символов — была уязвима к онлайн-атакам полного перебора. Пароли короче 18 символов оказались потенциально уязвимыми к офлайн-атакам, если учитывать возможности современного оборудования.
Повторяя и расширяя предыдущую работу Ли и др., мы оценили, как пароли шифруются и хранятся локально и в облаке.
Хотя большинство менеджеров используют надежное шифрование (например, AES-256), функции формирования ключей и механизмы их хранения различались, причем некоторые реализации были слабее других.
Выявленным критическим недостатком было хранение конфиденциальных метаданных (например, URL-адресов сайтов, имен пользователей) в открытом виде или с недостаточной защитой, что создает риск для конфиденциальности, даже если сам пароль зашифрован.
У нескольких менеджеров паролей были небезопасные настройки по умолчанию, такие как включение автоматического автозаполнения или отсутствие требования ввода мастер-пароля при перезапуске браузера, что увеличивало поверхность атаки.
Автозаполнение, будучи удобным, создает значительные векторы атак. Мы провели тестирование против известных классов эксплойтов.
Мы обнаружили, что несколько менеджеров остаются уязвимыми к атакам кликджекинга, когда вредоносный сайт накладывает невидимые элементы поверх легитимных кнопок интерфейса, чтобы обманом заставить пользователя активировать автозаполнение в поле, контролируемом злоумышленником.
Если на сайте есть уязвимость XSS, внедренный скрипт потенциально может взаимодействовать с DOM-элементами менеджера паролей для извлечения учетных данных — риск, отмеченный в более ранней работе Штока и Джонса.
Менеджеры, которые общаются с облачными сервисами для синхронизации или функций, были протестированы на подверженность атакам "человек посередине", которые могут внедрять вредоносный код или красть токены аутентификации.
В целом, безопасность улучшилась по сравнению с оценками пятилетней давности, но серьезные проблемы сохраняются. Ни один менеджер не был безупречным во всех трех категориях (генерация, хранение, автозаполнение). Встроенные в браузер менеджеры часто имели более простую и безопасную логику автозаполнения, но более слабые алгоритмы генерации. Сторонние расширения предлагали больше функций, но вносили большую сложность и увеличивали поверхность атаки. Мы определяем конкретные менеджеры, которые показали плохие результаты и которых следует избегать пользователям, заботящимся о безопасности.
13
147M+
4
Для пользователей: Выбирайте менеджеры с подтвержденной репутацией в области безопасности, включайте все доступные функции безопасности (например, двухфакторную аутентификацию) и будьте осторожны с автозаполнением. Для разработчиков: Реализуйте криптографически стойкие генераторы случайных чисел (CSPRNG) для генерации паролей, шифруйте все метаданные, применяйте безопасные настройки по умолчанию (например, всегда требовать мастер-пароль) и защищайте автозаполнение от манипуляций с интерфейсом. Для исследователей: Изучайте компромисс между удобством использования и безопасностью автозаполнения, разрабатывайте стандартизированные методологии оценки безопасности и исследуйте постквантовую криптографию для обеспечения безопасности на будущее.
Ключевой вывод: Исследование Эша и Руоти дает отрезвляющую проверку реальности: сами инструменты, призванные решить проблему с паролями, представляют собой лоскутное одеяло из уязвимостей. Ориентация индустрии на удобство и избыток функций в ряде случаев напрямую подрывает основные обещания безопасности. Вывод о том, что сгенерированные пароли могут быть слабыми, особенно губителен — он бьет в самое сердце ценностного предложения менеджера паролей.
Логическая структура: Статья блестяще структурирует атаку в соответствии с пользовательским путешествием: создание (генерация), хранение (storage) и использование (автозаполнение). Этот подход, основанный на жизненном цикле и напоминающий моделирование угроз в таких методологиях, как STRIDE от Microsoft, показывает, что слабости не изолированы, а системны. Недостаток в генерации снижает эффективность надежного хранения; недостаток в автозаполнении сводит на нет и то, и другое. Эта взаимосвязь часто упускается из виду при точечных аудитах.
Сильные стороны и недостатки: Сила исследования — в его комплексности и повторении предыдущих работ, что дает редкий долгосрочный взгляд на эволюцию безопасности. Массивный корпус из 147 миллионов сгенерированных паролей для анализа заслуживает похвалы. Однако в анализе есть недостаток, общий для многих оценок безопасности: это в основном черный ящик, функциональное тестирование. Он определяет, что сломано, но дает меньше понимания почему с точки зрения разработки программного обеспечения — были ли эти недостатки вызваны сжатыми сроками, неверным пониманием спецификаций или отсутствием проверки безопасности? Более того, хотя в нем упоминаются Руководящие принципы цифровой идентификации NIST, более глубокое погружение в то, как эти менеджеры соответствуют (или не соответствуют) стандартам, таким как FIPS 140-3, или требованиям безопасности, изложенным в предложениях IETF по Password Authenticated Key Exchange (PAKE), добавило бы значительный вес.
Практические рекомендации: Для корпоративных команд безопасности эта статья является мандатом на тщательную проверку одобренных менеджеров паролей. Полагаться на репутацию бренда недостаточно. Контрольные списки закупок должны включать конкретные тесты на случайность генерации (например, с использованием стандартизированных наборов тестов, таких как Dieharder или STS от NIST), шифрование метаданных и поведение автозаполнения при моделировании атак. Для разработчиков урок заключается в том, чтобы отдавать приоритет простоте и безопасным настройкам по умолчанию. Самый безопасный механизм автозаполнения может быть самым простым: ручное "нажатие для заполнения", требующее явного, осознанного действия пользователя, как предлагается в исследованиях Калифорнийского университета в Беркли об интерфейсах явного согласия. Будущее заключается не в попытке сделать интеллектуальное, автоматическое заполнение идеально безопасным, а в разработке минимально навязчивых, но максимально явных пользовательских взаимодействий, которые оставляют человека в контуре принятия критически важных решений по безопасности.
Оценка случайности генерации паролей основывалась на расчете энтропии Шеннона $H$ для сгенерированных паролей:
$H = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$
где $P(x_i)$ — вероятность появления символа $x_i$ в заданной позиции. Для по-настоящему случайного выбора из набора из $C$ символов максимальная энтропия на символ составляет $\log_2(C)$. Для набора из 72 символов (26 строчных + 26 заглавных + 10 цифр + 10 символов) макс. $H_{char} \approx 6.17$ бит. Таким образом, 10-символьный пароль имеет теоретический максимум около 61.7 бит энтропии.
Исследование показало, что смещения в алгоритмах некоторых менеджеров снижали эффективную энтропию. Уязвимость к офлайн-атакам оценивалась с использованием расчетной скорости взлома $R$ (хешей в секунду) и пространства паролей $N$:
$\text{Время на взлом} \approx \frac{N}{2 \times R}$
Принимая высокую скорость $10^{10}$ хешей/сек (в пределах возможностей современных GPU-кластеров), пароль с энтропией менее ~65 бит ($N = 2^{65}$) может быть взломан за приемлемое время для мотивированного злоумышленника.
Ключевая диаграмма 1: Смещение в распределении символов. Столбчатая диаграмма, сравнивающая наблюдаемую и ожидаемую частоту типов символов (заглавные, строчные, цифры, символы) для нескольких менеджеров паролей. У нескольких менеджеров наблюдалось статистически значимое отклонение (p < 0.01) от ожидаемого равномерного распределения, с чрезмерным представлением цифр в определенных позициях.
Ключевая диаграмма 2: Энтропия в зависимости от длины пароля. Точечная диаграмма, показывающая измеренную энтропию для каждого менеджера при разной настроенной длине пароля (8, 12, 16, 20 символов). Диаграмма показывает, что хотя большинство менеджеров приближаются к теоретической линии энтропии для более длинных паролей, несколько из них отстают для более коротких длин (8-12 символов), группируясь ниже линии, что указывает на более слабую случайность.
Ключевая диаграмма 3: Матрица уязвимостей автозаполнения. Тепловая карта с менеджерами на оси Y и классами уязвимостей (Кликджекинг, Утечка через XSS, Сетевое внедрение) на оси X. Ячейки окрашены в зеленый (не уязвим), желтый (частично/вариативно уязвим) и красный (уязвим). Эта визуализация наглядно показывает, какие менеджеры наиболее рискованны с точки зрения атак на автозаполнение.
Кейс: Оценка безопасности автозаполнения "Менеджера X".
Шаг 1 - Картирование функций: Документируйте, как Менеджер X активирует автозаполнение: Автоматически заполняет? Показывает выпадающий список? На какие атрибуты DOM он полагается (id, name, class, placeholder)?
Шаг 2 - Моделирование угроз: Примените модель STRIDE.
Шаг 3 - Выполнение тестов: Создайте тестовую веб-страницу, которая систематически пытается использовать каждый вектор угрозы. Для кликджекинга создайте перекрывающиеся прозрачные элементы. Для XSS смоделируйте скрипт, читающий свойство `value` заполненных полей.
Шаг 4 - Анализ и оценка: Оцените каждую уязвимость на основе вероятности и воздействия (например, с использованием оценки DREAD). Совокупная оценка определяет общий рейтинг безопасности автозаполнения для Менеджера X.
Такой структурированный подход выходит за рамки случайного тестирования и обеспечивает комплексное покрытие.
1. Интеграция с WebAuthn/Passkeys: Будущее — без паролей. Следующий этап эволюции менеджеров паролей — стать основными брокерами для паскейов (на основе W3C Web Authentication API). Необходимы исследования безопасной синхронизации и восстановления закрытых ключей паскейов между устройствами — задача, отмеченная альянсом FIDO.
2. Контекстно-зависимое, основанное на рисках автозаполнение: Вместо бинарной логики заполнения/не заполнения будущие менеджеры могли бы использовать машинное обучение для оценки легитимности страницы (проверка возраста домена, SSL-сертификата, репутационных оценок) и контекста пользователя (типичное время входа, устройство), чтобы корректировать поведение автозаполнения, требуя дополнительной аутентификации для сценариев с высоким риском.
3. Формальная верификация и безопасное оборудование: Критические компоненты, особенно генератор случайных чисел и основные процедуры шифрования/дешифрования, могут быть формально верифицированы с помощью таких инструментов, как Coq или Tamarin Prover. Интеграция с доверенными платформенными модулями (TPM) или Secure Enclaves для хранения ключей может повысить безопасность для высокоценных целей.
4. Децентрализованные и ориентированные на пользователя архитектуры: Переход от централизованных облачных хранилищ к децентрализованным протоколам (например, на основе безопасных вычислений с несколькими участниками или персональных серверов) может смягчить риски крупномасштабных взломов провайдеров. Это согласуется с более широким видением проекта "Solid" для персональных хранилищ данных.