Менеджеры паролей: облачное хранение против локального по уровню защиты

После инцидента многое зависело от силы мастер-пароля и настроек защиты конкретного хранилища. Сам факт шифрования на сервере снижает риск, но не отменяет его.

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

У облачного и локального менеджера может быть схожая криптографическая основа. Различается прежде всего то, где лежат данные и кто отвечает за их доступность.

Архитектура шифрования: что делают Bitwarden и KeePass

Bitwarden шифрует содержимое хранилища на устройстве до отправки на сервер. Для симметричного шифрования используется AES-256. Ключ, которым шифруются данные, получают из мастер-пароля с помощью функции выработки ключа: в Bitwarden доступны PBKDF2-SHA-256 и Argon2id. Это альтернативные варианты, а не два последовательных слоя одной настройки. Пользователь выбирает один из них и задаёт поддерживаемые клиентом параметры.

В документации Bitwarden для PBKDF2 указано значение по умолчанию в 600 000 итераций. Это настройка именно этого варианта. Если выбран Argon2id, вместо числа итераций PBKDF2 важны параметры Argon2id, в том числе затрачиваемая память и вычислительная работа. Их нельзя объединить в один показатель и сравнивать без учёта конкретной конфигурации.

KeePass хранит базу в файле, обычно с расширением kdbx. Сервер разработчика для работы с файлом не обязателен. KeePass поддерживает AES-256, ChaCha20 и Twofish, а для получения ключа предлагает AES-KDF или Argon2. Параметры можно настраивать. Чем выше вычислительная стоимость открытия базы, тем дороже перебор мастер-пароля, но тем больше ресурсов требуется и владельцу. Поэтому настройку проверяют на самом слабом устройстве, где файл придётся открывать.

В обоих случаях зашифрованная база не должна раскрываться серверу или облачному хранилищу, если шифрование и клиент реализованы корректно. Но это не означает, что все метаданные защищены одинаково. Сервер может обрабатывать сведения, необходимые для синхронизации и работы аккаунта; объём и характер таких данных зависят от конкретного сервиса. Нельзя автоматически переносить выводы о Bitwarden на другие продукты. У разных менеджеров отличаются архитектура, набор доступных параметров и то, как устроено хранение.

Синхронизация через интернет и локальный файл

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

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

Локальная база не требует аккаунта у поставщика менеджера, но синхронизация между устройствами никуда не исчезает. Файл можно переносить вручную или разместить в сервисе хранения, использовать сетевую папку либо настроить инструмент синхронизации. Каждый способ меняет профиль риска. Ручное копирование уменьшает зависимость от сторонней инфраструктуры, но повышает вероятность открыть устаревшую копию. Автоматическая синхронизация удобнее, однако создаёт больше мест, где хранится файл.

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

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

Мастер-пароль и многофакторная аутентификация

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

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

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

У локального KeePass нет встроенной облачной учётной записи, для которой можно включить MFA в том же смысле. Ключевой файл может выступать дополнительным фактором доступа к базе, но его нужно хранить отдельно от неё. Если положить файл базы и ключевой файл в одно место, разделение теряет смысл. Также не стоит считать, что два фактора помогут, если устройство уже разблокировано и злоумышленник получил доступ к открытой базе.

Настройки получения ключа требуют отдельного внимания. Если в Bitwarden используется PBKDF2, проверяют актуальность числа итераций и учитывают рекомендации сервиса. Если выбран Argon2id, настраивают его параметры отдельно. Нельзя говорить, что Argon2id работает вместе с дефолтными 600 000 итерациями PBKDF2: это разные варианты получения ключа. В KeePass настройки также нужно соотносить с возможностями устройств. Слишком слабые параметры удешевляют перебор, чрезмерно тяжёлые могут сделать повседневное открытие базы неудобным.

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

Где различаются риски и что не решает выбор модели

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

Локальная модель сокращает зависимость от серверов поставщика, но повышает ответственность владельца за сохранность файла. Потеряли базу, повредили диск, забыли мастер-пароль и не сохранили нужные ключевые материалы — восстановление может оказаться невозможным. Кража ноутбука тоже опасна, особенно если диск не зашифрован. BitLocker, FileVault или LUKS снижают риск доступа к данным на выключенном устройстве, но не защищают открытую сессию от человека или вредоносной программы, уже получивших доступ к системе.

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

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

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

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

Автозаполнение и побочные каналы утечки

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

Для снижения риска проверяйте адрес сайта до заполнения, держите браузер и расширение обновлёнными и не устанавливайте сомнительные дополнения. Автоматическая подстановка удобна, но ручное подтверждение иногда помогает заметить неправильный домен. Универсального переключателя, который устранит все риски браузерной среды, нет.

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

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

Выбор зависит от того, какой риск вы готовы взять на себя

Облачный менеджер подходит тем, кому важны синхронизация и восстановление доступа с нескольких устройств. При выборе такой модели нужны сильный уникальный мастер-пароль, включённая MFA и понимание того, как устроены резервные копии и восстановление аккаунта. Если в настройках выбран PBKDF2, отдельно проверяют его параметры; если Argon2id, настраивают именно Argon2id. Значение по умолчанию PBKDF2 не переносится на альтернативную функцию.

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

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

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