Содержание статьи
info
Все выводы в статье — это личное мнение автора со множеством нюансов и допущений, о которых я постарался упомянуть. Менеджеры паролей — обширная категория продуктов, и у каждого пользователя найдутся как свои субъективные предпочтения, так и объективные доводы в свете их конкретной ситуации и опыта. Я постарался объять необъятное, сохраняя, насколько это возможно, объективность, при этом у меня нет конфликта интересов, поэтому рекламировать того или иного вендора я не стану. Буду рад, если статья окажется кому‑то полезной, вызовет дискуссии в комментариях или кто‑то из читателей укажет на возможные ошибки.
Давай начнем с истории. Жил‑был Петя, в школе он создавал множество аккаунтов на сайтах, записывая пароли (или один‑единственный пароль, что уж греха таить) на бумажке, которую бережно хранил в одной из книг. В старших классах ему пришла в голову идея, что пароли можно хранить в таблице на компьютере. Новые аккаунты он заносил в таблицу, а старые не стал, ведь браузер и приложения не просили его логиниться заново. В универе Петя поменял компьютер, таблица с паролями перекочевала на флешку, а на новом компьютере появился еще один файл. Поскольку иногда приходилось создавать аккаунты вне дома, то на телефоне у Пети тоже хранилась парочка паролей, так же как и в записной книжке. Притом он уже не помнил, от чего именно некоторые из записанных паролей. А еще в недрах его устройств хранились волшебные SSH-ключи и магические сертификаты VPN, которые ему помогли установить админы на первой работе. В общем, он хранил пароли на разных устройствах — старых и новых, личных и рабочих, в разных файлах и в книжке, не помнил, от чего некоторые из этих паролей, или, еще хуже, помнил, от чего пароль, но не помнил, где его записал!
Минусы блокнотов, бумажек и стикеров, которые так любят клеить на монитор сотрудницы бухгалтерии, очевидны: они могут выпасть и потеряться, на них можно пролить кофе и безвозвратно расстаться с паролем, соответствующим всем политикам безопасности (ведь мы все создаем только сложные пароли, не так ли?). Кроме того, их может просто увидеть и запомнить другой человек. Основная проблема хранения подобной информации в телефоне заключается в том, что на нем ты не будешь держать сертификаты, API-токены и SSH-ключи, так как это просто физически неудобно. Ну и если телефон украдут, то пароли и куча другой конфиденциальной информации попадут в руки злоумышленников. У заметок и таблиц еще и шифрование отсутствует, а таскать каждый день на работу ноутбук с файлом, только чтобы иметь при себе все нужные записи, ты не будешь.
Так что же делать? Идеальное решение — никогда не сохранять пароли и не забывать пить таблетки для улучшения памяти. Но к сожалению, мы не в состоянии запомнить сотню учетных записей, поэтому такой вариант Петя сразу отмел. За решением вопроса Петя полез в интернет, залогинился в одну из социальных сетей, и в этот момент перед ним появился поп‑ап, предлагающий сохранить пароль. Неужели браузер может хранить все его пароли?
Браузерные хранилища
Самое простое на первый взгляд решение — это воспользоваться встроенным менеджером паролей браузера. На самом деле это не менеджер паролей (почему — разберемся позже), а пока давай называть его хранилищем паролей браузера (ХПБ). Плюсы очевидны: во‑первых, решение работает из коробки; во‑вторых, данные сами подставляются в формы; в‑третьих, как заметят опытные пользователи, ХПБ позволит избежать подстановки учетных данных на фальшивых сайтах. На этом, собственно, плюсы заканчиваются. Дальше идут только минусы, и главный из них — это отсутствие шифрования.
Дело в том, что браузер создавался не для хранения паролей, а поэтому безопасность пользователей стоит для него ниже удобства. Разбираться с паролями, которые необратимо зашифровались, никто не хочет, поэтому и хранится база во вполне конкретном месте, шифруется по известному алгоритму, а иногда и ключ для дешифровки лежит рядом. Именно по этой причине, строго говоря, браузерные менеджеры паролей создают скорее психологический комфорт для пользователя, чем реальный барьер для злоумышленника.
Кто‑то скажет, что все это, конечно, здорово, но насколько действительно легко получить доступ к паролям, хранящимся в браузере? Резонный вопрос! Как отмечает Р. Д. Рассел из компании Fractional CISO, достать пароли из браузеров Firefox, Chrome и Edge на Windows уже в 2022 году было вполне тривиальной задачей, которая решается с помощью простого питоновского скрипта. А Nik Zerof писал на «Хакере», как сделать подобный стилер на плюсах, еще в 2018 году.
А что же в 2024-м? Давай рассмотрим этот вопрос на примере Chrome в различных ОС.
На Windows Server 2019 Standard все совсем печально, база данных SQLite 3 и мастер‑ключ от нее хранятся в следующих файлах:
C:\Users\$username\AppData\Local\Google\Chrome\User Data\Default\Login Data
C:\Users\$username\AppData\Local\Google\Chrome\User Data\Local State
Chrome блокирует базу данных, пока он работает. Мастер‑ключ закодирован в Base64 и скрывается в переменной encrypted_key
, причем при открытии файла с мастер‑ключом никто не запрашивает дополнительных подтверждений. Соответственно, открыв, например, файл из письма, злоумышленник получает доступ и к базе данных, и к ключу дешифровки.
DPAPI и шифрование App-Bound
Внимательный читатель наверняка обратил внимание на то, что мы получили доступ к базе данных и к мастер‑ключу в контексте пользователя. Дело в том, что в Windows с 2000 года применяется механизм DPAPI (Windows Data Protection API), который позволяет шифровать данные, и которым пользуется Chrome. Оба файла (база данных и файл с мастер‑ключом от нее) представляют собой DPAPI blob. Немного упрощая, можно сказать, что в контексте пользователя этот блоб автоматически расшифровывается хранящимся в LSASS хешем пароля пользователя и мастер‑ключом DPAPI. Сделать это от имени другого пользователя на том же компьютере было бы невозможно.
Однако вредоносное ПО, которое старается получить твои пароли, будет в большинстве случаев работать именно в контексте пользователя, его установившего. Это в данном случае делает защиту DPAPI не слишком высоким барьером. Вне контекста пользователя можно попытаться получить хеш пароля юзера и уже расшифрованный мастер‑ключ DPAPI атаками на LSASS, или, если твой компьютер все еще использует классический BIOS, то атакой холодной перезагрузки.
В Google недавно озаботились этой проблемой и с версии Chrome 127 (23 июля 2024 года) внедрили новый механизм — шифрование с привязкой к приложению. С ним данные может получить не любой процесс, запущенный в контексте пользователя, а только Chrome, что делает ситуацию похожей на происходящее в macOS и Linux. Однако новый механизм пока действует только для файлов cookie, и на пароли пользователей пока не распространяется.
На macOS все сложнее. База паролей хранится в файле
/Users/$username/Library/Application Support/Google/Chrome/User Data/Default/Login Data
А вот мастер‑ключ Chrome Safe Storage содержится уже не в простом файле, а в связке ключей (Keychain), и по состоянию на 2024 год в macOS Ventura 13.2 для его извлечения у пользователя запрашивается пароль.
В Linux ситуация аналогичная тому, что происходит на macOS, то есть база хранится по пути ниже, а для ее расшифровки потребуется мастер‑ключ Chrome Safe Storage Control из связки ключей (например, gnome-keyring), для доступа к которому также необходимо ввести пароль пользователя, если, конечно, ты специально не задал другой пароль для связки ключей изначально.
~/.config/google-chrome/Default/Login Data
Как видим, при использовании ХПБ вредоносное ПО действительно имеет все шансы добраться до наших паролей. На Windows это совсем просто, а на macOS и в Linux придется приложить чуть больше усилий. Этот недостаток ХПБ был использован, например, вымогателем Qilin в июле 2024-го, когда перед шифрованием он вытаскивал все учетные данные браузеров Chrome в домене.
Отсутствие шифрования позволяет твоим коллегам или родственникам получить и физический доступ к паролям, если ты оставишь компьютер незаблокированным или вообще не используешь пароль на этом устройстве. А браузерные расширения, которым мы не глядя даем все запрашиваемые права, могут просто скачать всю базу в текстовом виде.
У ХПБ есть еще несколько минусов. Кто‑то скажет, что база паролей хранится локально, но на самом деле мы этого не знаем, мы просто воспринимаем это как факт. Еще один минус заключается в том, что ХПБ не могут хранить ничего, кроме учетных данных и номеров банковских карт. API-ключи, сертификаты или документы и прочее ты там не сохранишь. И последнее: мы зависимы от одного браузера на одном девайсе, то есть, храня пароли в Safari, ты не можешь воспользоваться ими в Chrome. А если захочешь залогиниться в один из видеосервисов на компьютере своей девушки, то здесь вообще беда: твой девайс вместе с сохраненным паролем остался дома.
Менеджеры паролей
Изучив ХПБ, Петя остался недоволен, ведь его пароли там не будут в безопасности. Но как тогда хранить все нажитое непосильным трудом?
Вероятно, все слышали про Apple Keychain или менеджер паролей Google, которые настроены почти на каждом яблочном или Android-устройстве. Это облачные менеджеры паролей (ОМП), которые работают на уровне экосистемы вендора. А, например, Opera Sync делает нечто похожее, синхронизируя всю активность браузера Opera на разных устройствах, однако это не исключает уже упомянутых минусов ХПБ. Получается забавная ситуация: помнишь, что Chrome на платформе macOS полагался на Apple Keychain? Получается, что ХПБ используют другой, сторонний ОМП для обеспечения безопасности твоих паролей. Так к чему эти посредники?
Думаю, самое время сделать небольшое отступление и обсудить, какие вообще существуют менеджеры паролей. Я бы разделил их на четыре типа:
- облачные менеджеры паролей (ОМП);
- локальные менеджеры паролей (ЛМП);
- корпоративные менеджеры паролей (КМП);
- детерминистические менеджеры паролей (ДМП).
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»