Пароль «рыба-меч»
Выбираем облачный менеджер паролей
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? Получается, что ХПБ используют другой, сторонний ОМП для обеспечения безопасности твоих паролей. Так к чему эти посредники?
Думаю, самое время сделать небольшое отступление и обсудить, какие вообще существуют менеджеры паролей. Я бы разделил их на четыре типа:
- облачные менеджеры паролей (ОМП);
- локальные менеджеры паролей (ЛМП);
- корпоративные менеджеры паролей (КМП);
- детерминистические менеджеры паролей (ДМП).
ОМП хранят данные на серверах вендора и работают как SaaS-решения, ЛМП хранят данные в виде локального файла на устройстве, КМП хранят информацию на сервере компании (их можно условно назвать локальным облаком), а ДМП вообще ничего нигде не хранят, но создают пароль на локальном устройстве каждый раз заново как производную от мастер‑пароля и домена. По сути, выбор менеджера пароля сводится в первую очередь к выбору места хранения данных, то есть доверия вендору, и, в меньшей степени, к цене и привлекательности интерфейса. Все остальные компоненты более или менее одинаковы.
Сравнить интерфейс и цены менеджеров паролей ты можешь и сам, поэтому давай посмотрим на них под другим углом, а именно заглянем им под капот и попробуем выяснить, насколько они соответствуют заявленному описанию и защищают нас от известных угроз. Для этого определимся с моделью угроз, чтобы понять, как же нам оценивать менеджеры паролей, ведь они не могут защитить от всего на свете.
Предлагаю считать, что мы полностью доверяем нашему устройству на хардварном уровне, а также на уровне ОС, то есть мы не будем рассматривать варианты, когда коварный производитель намеренно пытается вытащить все твои пароли через бэкдор. Поэтому остановимся на четырех основных векторах:
- враждебная среда ОС (вредоносное ПО, физический доступ, память устройства);
- уязвимости приложения (уязвимости ядра программы и неожиданные вещи в начинке);
- враждебная среда веб‑ресурсов (автозаполнение и фишинг);
- неопределенность обмена данными (облако, синхронизация, шеринг паролей).
Собрав 25 продуктов, Петя начал отсекать лишнее. Здесь рассматриваются персональные решения, поэтому о КМП («Пассворк», Vault, Passbolt) говорить не буду. ДМП также не стану рассматривать из‑за их редкости и ограниченности. ЛМП мы тоже оставим в стороне, так как там речь скорее идет о неофициальных портах для разных платформ, что не позволяет выделить функциональность ядра продукта (KeePass, pass).
Из обзора были также исключены заброшенные проекты (Horcrux, Mitro, Padloc, RememBear), сомнительные (PassKeep), зависимые от экосистемы или устройства (iCloud Keychain, Google Password Manager). Нелегким решением было также исключить вендоров, блокирующих российские IP-адреса (Norton Password Manager, NordPass, ProtonPass), а также тех, чьи продукты нельзя оплатить из России без дополнительной головной боли (российской картой или через магазин мобильных приложений), поэтому платные решения были практически исключены из анализа (1Password, Dashlane). Все‑таки взаимодействовать с решениями, которые изначально настроены к тебе негативно, — довольно рискованное дело, а менеджер паролей — это как‑никак про минимизацию рисков. При тестах я пользовался российской почтой (mail.ru) и российским IP-адресом.

Жирным в таблице выделены цены тех продуктов, которые можно приобрести с российской карты.
Работа «из коробки» и интерфейс
Один из первых критериев, на которые обычно обращают внимание, — это удобный интерфейс и простая настройка. Раз уж мы уходим от ХПБ, то в ОМП все должно быть плюс‑минус так же легко и интуитивно.
Вот ты скачиваешь и запускаешь менеджер паролей. Но Zoho Vault и Kaspersky сначала требуют создать аккаунт в их экосистеме и только потом уже ввести мастер‑пароль для создания самого хранилища. Мелочь, но неприятно. Стоит отдать должное Kaspersky, он был единственным, кто предложил прочитать пользовательское соглашение. Еще стоит отметить, что у Zoho Vault не работает регистрация на адреса mail.ru и оплата из российского сегмента мобильного магазина приложений недоступна, но бесплатной версии нам вполне хватит.
Внутри функции перечисленных программ более‑менее совпадают. Везде можно добавлять разные категории данных (учетные данные, банковские карты, заметки), создавать папки, искать по хранилищу. Если захочешь, то мастер‑пароль можно всегда поменять! Важная функция — это импорт данных, у большинства она есть, можно импортировать как из CSV-файлов, так и из браузера или другого менеджера паролей. А вот у Zoho Vault такой функции нет вообще, тогда как Kaspersky позволяет импортировать только из CSV-файлов. У всех конкурентов в этом плане возможностей больше.
Дизайн — это уже субъективный критерий. Лично мне Keeper показался пестрым, с обилием функций, от которых разбегаются глаза. У Bitwarden дизайн очень простой, как будто его делали лет десять назад, а в левой части окна всегда висит «пустая папка», что очень раздражает. Я как‑то ожидал большего от проекта такого уровня.

У Sticky Password, Enpass и Kaspersky дизайн спокойный и интуитивно понятный, всё по делу. Вот не хотел ничего плохого говорить про LastPass, но после запуска в приложении сразу поехала верстка... Хоть интерфейс и выполнен неплохо, но, как и в Keeper, от обилия функций разбегаются глаза. Главный минус состоит в том, что после создания пароля я так и не понял, как открыть карточку, чтобы посмотреть запись.


В RoboForm без ста граммов не разберешься. Для входа нужно понять, как обойти назойливое предложение добавить расширение в Safari. Делается это через смену мастер‑пароля. По идее, у RoboForm, так же как и у Kaspersky, нужно создать аккаунт в экосистеме, но этот шаг я удачно обошел, в итоге оставшись без доступа в профиль. Потом меня встретил интересный баг: окно приложения показывалось поверх других окон, баг пропал на следующий день. Дальше — больше: добавить учетные данные нельзя. Вот и всё, приехали. Чтобы добавить учетную информацию, необходимо залогиниться на веб‑ресурсе, а затем сохранить пароль в хранилище через расширение, но вписать в это хранилище свой собственный пароль из головы не получится.

Не буду долго останавливаться на вопросе кросс‑платформенности, то есть поддержке менеджером паролей всех устройств и интерфейсов. Я использовал критерий «Основные ОС», к которым относятся Windows, macOS, Linux, Android и iOS — наиболее популярные десктопные и мобильные платформы. А также «Основные браузеры», к которым я отнес Chrome, Firefox, Safari и Edge. Практически все изученные мною программы поддерживают весь упомянутый зоопарк, проблемы возникли только с отсутствием Linux у Kaspersky и Sticky Password.
Уязвимости ПО и враждебная среда в рамках ОС
Вот мы и подобрались к определенной нами модели угроз. Вначале давай разберемся с проблемой, которую мы вменяли в вину ХПБ, — нестойкостью перед вредоносным ПО, эксплуатирующим уязвимости в самих приложениях менеджеров паролей, в шифровании базы данных и в буфере обмена.
Уязвимости приложений присущи и ХПБ, и ОМП. Как будто в браузерах не бывает зиродеев и багов — чего стоят только недавние CVE-2024-29943 и CVE-2024-29944 в Firefox. В ОМП такие уязвимости тоже находятся: вот, например, CVE-2021-40539 в Zoho или проблема некорректной работы API у Keeper в 2018 году. Здесь мы ничего сделать не можем, нам остается только своевременно обновляться до последней версии.
Более интересным выглядит второй класс угроз, то есть кейлоггеры, а также трояны, умеющие делать снимки экрана и извлекать данные из буфера обмена. Подобные вредоносы в большинстве случаев неплохо обнаруживаются антивирусами, хотя некоторые ОС встраивают в свои продукты всякие AI Explorer... К сожалению, только в Enpass есть настройка, блокирующая менеджер паролей при активации снимка экрана.
Для Windows также актуальна атака DLL Hijacking, ей подвержены почти все ОМП. А удаление данных из буфера обмена практически никак не защищает пользователя. Дело в том, что вредоносное ПО может сохранить состояние буфера обмена еще до того, как менеджер паролей очистит его от скопированного содержимого. Вот что пишет разработчик KeePass Доминик Райхль: «Ни KeePass, ни любой другой менеджер паролей не могут волшебным образом безопасно работать внутри зараженной шпионским ПО среде».
Функция очистки буфера обмена есть у половины рассмотренных ОМП, а вот функция автоматического выхода по истечении времени есть у всех. Ну хоть никто посторонний не сможет прочитать пароли в твое отсутствие, то есть угроза физического доступа ликвидирована. Хотя здесь есть один нюанс: базовые настройки безопасности у Bitwarden и Zoho Vault, конечно, так себе, придется полазать в них, чтобы приложение блокировалось при закрытии и чистило буфер обмена. Тогда как у Keeper, Enpass, Sticky Password и Kaspersky все работает из коробки. Стоит отметить, что ни один вендор не хранит мастер‑пароль или его производные в памяти устройства, что само по себе уже радует.
Нужно помнить, что приложения — это коммерческий продукт, который может подложить свинью самостоятельно: использовать Google Tag Manager, Firebase и прочие трекеры. Не буду вдаваться в подробности, для интересующихся есть потрясающий ресурс Exodus, где можно проверить любой менеджер паролей или другое приложение.
Враждебная среда веб-ресурсов
А теперь давай поговорим о самой востребованной функции как ХПБ, так и других ОМП — автозаполнении. Работает она так: веб‑страница сканируется, на ней обнаруживаются все формы, а дальше менеджер паролей подгружает имеющиеся учетные данные и вставляет их в найденные поля. Все очень просто и изящно, но что может пойти не так?
Во‑первых, фишинг — то есть ситуация, когда ты оказался на сайте, который выглядит как настоящий, но им не является. В этом случае и браузерный, и любой другой менеджер паролей тебя защитит, так как проверяет соответствие домена. Не поможет это, если разработчики допустят ошибку в методе распознавания домена, что и произошло с LastPass в 2016 году.
Вторая самая известная угроза — это атака Clickjacking на скрытые фреймы, которые контролируются злоумышленником. Дело в том, что злоумышленники при компрометации веб‑ресурса иногда подставляют скрытую форму логина через фрейм под видимую панель аутентификации, а менеджер паролей автоматически подставляет данные во все найденные формы, о чем ты даже и не узнаешь. Самый большой скандал произошел с Bitwarden, который знал об этой угрозе с 2018 года, но предпринял меры по ее минимизации только в 2023 году.
Еще одна неприятность — это вездесущие маркетологи. Некоторые веб‑ресурсы используют скрытые формы автозаполнения для сбора данных о пользователе. Все происходит так же, как и в упомянутой выше атаке, только собираются твои личные данные и почта для профилирования, и да, ты об этом тоже не узнаешь. Но под раздачу‑то могут попасть и пароли!
Если посмотреть на автозаполнение со стороны ОМП, то единственный способ соединить их с веб‑страницей — это установить расширение в браузере. Расширение имеет доступ ко всем страницам браузера и автоматически загружает в них встраиваемый скрипт (aka скрипт контента), чтобы на форме логина отрисовывались красивые значки и всплывающие окна выбора учетных данных.
Хотя встраиваемый скрипт и работает в изолированной среде, это всего лишь концепция, а за ее соблюдением должен следить разработчик. В 2017 году оказалось, что веб‑ресурс может свободно менять переменные во встраиваемых скриптах расширения LastPass (раз и два). Для отрисовки элементов встраиваемый скрипт чаще всего использует те же самые привилегированные фреймы, которыми можно манипулировать, как это произошло у Keeper в 2017 году или у LastPass в 2019 году. Наконец, можно банально подменить встраиваемый скрипт с последующим прямым запросом данных у менеджера паролей. Например, так было у TrendMicro в 2016 году (инцидент описан здесь и здесь).

Если ты думаешь, что проблемам с автозаполнением подвержены только веб‑страницы и расширения, то спешу тебя огорчить: на мобильных устройствах могут использоваться приложения‑клоны или угроза может исходить из некорректного использования WebView API, которое вылилось в уязвимость AutoSpill на Android-устройствах. В обоих этих инцидентах были замечены LastPass, Keeper, 1Password, RoboForm и Enpass.
Как мы видим, от фишинга нас защищают все менеджеры паролей, атакам Clickjacking и краже данных рекламщиками подвержены, к сожалению, также все, а у расширений есть и свои проблемы. Чтобы защититься, отключи автозаполнение при загрузке страницы, чтобы данные подставлялись только после твоего явного разрешения, а также вовремя устанавливай обновления. Но не стоит отказываться от этой функции полностью, злоумышленнику будет намного труднее обмануть сразу и тебя, и менеджер паролей.
Неопределенность обмена данными
С ХПБ все неопределенно: вряд ли мы когда‑нибудь узнаем, где они хранят данные, кроме, разумеется, локальной копии. Вопрос неопределенности острее всего стоит у ОМП. Все рассмотренные ОМП на своих сайтах заявляют о том, что используют шифрование AES-256 с PBKDF2 SHA-256/512 для получения ключа шифрования, хранят данные по принципу нулевого разглашения и почти все используют сквозное шифрование. Звучит это все очень технологично и безопасно, но как же все‑таки дела обстоят в реальности?
В теории ты устанавливаешь программу на устройстве, вводишь мастер‑пароль и создаешь хранилище, которое представляет собой локальный файл, зашифрованный как раз тем самым алгоритмом AES-256. Ключ шифрования получается как производное от мастер‑пароля по алгоритму PBKDF2 HMAC SHA-256/512 (тот же самый Keeper использует миллион раундов, у RoboForm их всего 100 тысяч, а некоторые, например Bitwarden, дают возможность изменить количество раундов в настройках). Пока все понятно, все эти процессы проходят локально.
Дальше все ОМП можно разделить на три категории: те, что не хранят мастер‑пароль или его производные на сервере компании‑вендора (Sticky Password), те, что хранят (Bitwarden, LastPass, RoboForm, Keeper), и те, о которых в этом плане ничего не известно (Zoho Vault, Kaspersky).
Дело в том, что вендор должен аутентифицировать пользователя, то есть понять, что зашифрованное хранилище принадлежит именно тому, кто его запрашивает. Например, Kaspersky делает это через дополнительную аутентификацию в экосистемном аккаунте (помнишь тот шаг при регистрации, который показался нам неудобным?). Bitwarden сравнивает мастер‑пароль с двумя итерациями PBKDF2-SHA-256 и солью в виде email с результатом на сервере, а Sticky Password использует дополнительный ключ, никак не связанный с мастер‑паролем.
Некоторые предлагают включить 2FA, чтобы обезопасить доступ к хранилищу даже при наличии производных от мастер‑ключа на сервере вендора. Однако здесь есть один маленький, но очень важный нюанс. Все рассмотренные ОМП используют 2FA для аутентификации, которую выполняет вендор при синхронизации с облаком и обмене данными с пользователями, а шифрование хранилища здесь совершенно ни при чем. Ключ 2FA вендор хранит на своем сервере, поэтому для прохождения двухфакторной аутентификации необходимо подключение к интернету. Установив 2FA, ты не делаешь свое хранилище безопаснее и не усложняешь потенциальную задачу брутфорса для злоумышленника.
Возможно, кто‑то заметит, что многие вендоры пишут о наличии сквозного шифрования (E2EE). То есть данные шифруются до конечного устройства пользователя, а значит, никакой опасности нет. К сожалению, в данном случае это сквозное шифрование Шредингера: вендор может заявлять, что имеет сквозное шифрование, но, пока исходный код продукта не открыт, мы не можем подтвердить или опровергнуть это утверждение. Тем более что в большинстве случаев имеется в виду сквозное шифрование от устройства к серверу вендора для синхронизации хранилища, что по сути идентично традиционному HTTPS-соединению и ничем от него не отличается.
На самом деле есть и менее явная причина, по которой сервер вендора будет хранить твой мастер‑пароль и не будет считаться независимой стороной в сквозном шифровании. Все ОМП предлагают сервис веб‑хранилища: это когда ты можешь получить доступ к своим данным через веб‑интерфейс на сайте вендора. Упомянутая услуга идет в комплекте, отменить ее нельзя, а значит, при создании хранилища веб‑сервер автоматически становится одним из «твоих» устройств, и ему требуются ключи для дешифровки данных, передаваемых со сквозным шифрованием. Плюс он должен проводить операцию по преобразованию твоего мастер‑пароля, который ты ввел в веб‑форме, в ключ дешифровки хранилища, чтобы показать тебе заветные пароли. Никто из рассмотренных ОМП не говорит, что происходит с мастер‑паролем из веб‑формы, так же как и не говорит о безопасности своего веб‑приложения. Печально, что у многих вендоров в веб‑версии доступно больше настроек, чем в приложении, что заставляет клиента идти на риск.
Так в безопасности ли хранящиеся на серверах вендора данные, как об этом заявляют рекламные заголовки? Взломы ОМП случались, больше всего отличился LastPass, когда в 2011 и в 2015 годах хакеры смогли получить хеши паролей и соли, а в 2022 году из LastPass утекли еще и бэкапы баз данных пользователей, а URL-адреса сайтов в хранилищах вообще никак не шифровались. В 2016 году были взломаны хранилища Opera Sync, а в 2017-м серверы OneLogin.
Конечно, что произошло дальше с похищенными бэкапами и сколько из них удалось расшифровать — тайна, покрытая мраком, но стоит ли оно твоих нервов, когда после очередного взлома ты будешь приглядываться к каждому письму, избегая фишинга и социальной инженерии? В последнее время сформировался тренд на локальную синхронизацию, которая выполняется не через облако, а в домашней сети, когда устройства находятся рядом. В этом случае ОМП (Sticky Password, Enpass) становится сервисом синхронизации и интерфейса, играя роль ЛМП.
В идеале, конечно, ОМП — это сервис для хранения и синхронизации бэкапов зашифрованной базы данных твоих паролей. Но на практике все оказывается куда прозаичнее. Вендор действительно не видит ни твоего мастер‑пароля, ни содержимого хранилища, но ведь никто не говорил, что он не видит хеша твоего мастер‑пароля. Также никто не говорил, какие конкретно данные шифруются при передаче на сервер или откуда берется соль для всего этого криптографического рая.
В целом принцип нулевого разглашения и сквозное шифрование работают, но с некоторыми оговорками. И пусть тебя не смущают громкие термины, куча криптографических функций и заумные фразы. Единственное, что стоит между твоими нервами и безопасностью хранилища, — это твое доверие вендору. Ты либо веришь, что вендор действительно делает все так, как написал в рекламе, что он не занимается подпольным составлением радужных таблиц или не сможет выдать твои данные по первому запросу, либо, пользуясь ОМП, ты никогда не будешь уверен, что твои пароли не знает никто, кроме тебя.
Дополнительные функции
Одно из главных преимуществ ОМП над ХПБ состоит в том, что первые дают возможность анализировать пароли. Сюда относится традиционный «анализ пароля на сложность», а также ставшая популярной «проверка по утечкам». С анализом сложности паролей вроде бы все уже понятно. А как происходит проверка пароля на наличие в утечках?
Все рассмотренные ОМП (кроме Kaspersky) делают это, как ни странно, абсолютно одинаково, руководствуясь методом k-анонимности, разработанным Cloudflare. Твой локальный клиент посылает первые пять символов хеша SHA-1 каждого пароля на haveibeenpwned.com, который возвращает все пароли из утечек, начинающиеся с этих символов, а дальше эта выборка уже локально сравнивается с твоим полным паролем. Только Sticky Password отправляет данные не на haveibeenpwned.com, а в ARC, базу от компании Crossword Cybersecurity, хотя сути это не меняет. Сразу хочется спросить: сколько памяти съедают эти манипуляции и что именно раскрывается внешнему сервису?
Из всех ОМП только Bitwarden имеет открытый исходный код. Давай заглянем в него. Запрос отправляется с твоей машины, никто его не проксирует, то есть сторонний сервер, кроме части хеша, получает твой IP-адрес и юзер‑агент, а также при некоторых запросах домен и имя пользователя. Вот и весь анализ дарквеба, о котором пишут ОМП на своих сайтах. А Kaspersky отправляет весь SHA-256-хеш непонятно куда (вероятно, на свои серверы) и производит сравнение там. Причем отключить эту функцию, похоже, нельзя, поэтому давай сразу считать, что у Kaspersky хранятся SHA-256-хеши всех твоих паролей. Ну хоть без сторонних сервисов, и то хорошо.
Еще одна интересная функция — это доступ при экстренных обстоятельствах. Ты назначаешь какого‑либо пользователя ОМП своим экстренным контактом, тот, в свою очередь, должен принять приглашение, посылая тебе свой публичный ключ, а на третьем этапе ты подтверждаешь, что все идет по плану, шифруя мастер‑пароль публичным ключом экстренного контакта. В нужный момент твой экстренный контакт запрашивает доступ, и ему приходит твой мастер‑пароль, который он может расшифровать своим приватным ключом. В целом задумка интересная и может служить неплохим решением на случай утери мастер‑пароля. Примерно по такому же принципу происходит и шеринг данных с другими пользователями, так что и эта функция в целом безопасна.
Самая фееричная фича — это восстановление доступа. Казалось бы, как такое возможно, если никто вроде как ничего не хранит на своих серверах? Указанная функция у Keeper предполагает запоминание секретной фразы, шифрующей мастер‑пароль, который затем отправляется на сервер вендора. Но LastPass не был бы LastPass’ом, если бы не стал еще и сохранять эту секретную фразу на устройстве пользователя без уведомления клиента о подобном сервисе. Все другие ОМП функцией восстановления доступа не обладают.
Выводы
Петя проделал большой путь и понял главное — по сути, ОМП по сравнению с ХПБ позволяют:
- шифровать базу;
- хранить что‑то, кроме учетных данных;
- синхронизировать базу между устройствами;
- анализировать пароли.
Для обеих этих категорий программ присущи одни и те же типы угроз, но атаковать ОМП для злоумышленника куда сложнее, чем ХПБ. А если под тебя проводится целевая атака, то будь уверен, что доступ к хранилищу злоумышленник точно получит. В любом случае ХПБ — это намного лучше, чем стикер на экране, а ОМП — это еще лучше, чем ХПБ. При этом не все ОМП рождены равными, поэтому, будешь ли ты использовать ХПБ или ОМП и какой именно выберешь баланс между удобством использования и рисками, зависит только от тебя.
Браузерные | Облачные | |
---|---|---|
Бесплатный | + | +– |
Работа из коробки | + | +– |
Простой интерфейс | + | + |
Автозаполнение | + | + |
Уязвимости автозаполнения | Есть | Есть |
Уязвимость к вредоносному ПО | Есть | Есть |
Уязвимость физического доступа | Есть | – |
Уязвимость к фишингу | – | – |
Очистка буфера обмена | – | + |
Автовыход/блок | – | + |
Категории данных | – | + |
Анализ паролей | – | + |
Доступ на всех устройствах | – | + |
Шифрование БД | – | + |
Только локальная БД | Неизвестно | +– |
Только локальное содержание БД | Неизвестно | +– |
Только локальный мастер‑пароль | N/A | +– |
Идеального решения не существует, но постараюсь собрать все рекомендации воедино.
- При создании хранилища отключи функцию восстановления доступа.
- Не ставь флажок «Сохранить мой мастер‑пароль» при входе в хранилище, иначе он будет сохранен в памяти твоего устройства.
- Отключи функцию «Проверка пароля по утечкам», так больше шансов, что ни целый хеш, ни его часть с твоими метаданными не утекут за пределы инфраструктуры вендора.
- Не используй автозаполнение! Пусть менеджер паролей будет рекомендовать, что и куда подставить, но финальное решение должно всегда оставаться за тобой.
- По возможности не используй веб‑версию менеджера паролей, это уменьшит шансы того, что твой мастер‑пароль останется на сервере вендора.
- Сузь область применения авторекомендаций, исключив поддомены веб‑ресурса при подсказках. И по возможности ограничь количество предложений одним или двумя.
- Если есть подозрение, что ты зашел не в ту дверь, лучше сразу же смени пароль и добавь 2FA к веб‑ресурсу.
- Наконец, включай антивирус и обновляй ПО вовремя, это убережет тебя от банальных инфостилеров и известных уязвимостей.
Помни, что менеджер паролей — это коммерческий продукт, который сделан людьми. Используй только тот, которому искренне доверяешь, иначе спокойно спать ты точно не сможешь.