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

Это важное различие: при такой утечке злоумышленник не обязательно получает пароли в открытом виде, но может унести шифротекст и перебирать варианты мастер-пароля уже у себя.

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

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

Архитектура безопасности: Zero-Knowledge в облаке и контейнеры kdbx

Облачные менеджеры, например Bitwarden и 1Password, синхронизируют зашифрованное хранилище через серверы провайдера. В типичной схеме приложение на устройстве получает мастер-пароль, формирует из него криптографический ключ и использует его для защиты данных. На сервер отправляется зашифрованная версия хранилища, а не пароль в открытом виде. Архитектуру, в которой провайдер не должен иметь возможности расшифровать содержимое пользовательского сейфа, называют Zero-Knowledge, или нулевым разглашением.

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

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

Ни одна колонка не означает автоматически «безопаснее». Облако добавляет сервер и провайдера в модель доверия. Локальный файл сокращает число обязательных участников, зато требует от владельца аккуратной эксплуатации.

Криптографическая защита и автономный перебор

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

PBKDF2 и Argon2 относятся к таким функциям, но устроены по-разному. PBKDF2 многократно выполняет вычисления с паролем и солью. Argon2, в частности вариант Argon2id, дополнительно может требовать существенную память на каждую попытку. Это затрудняет распараллеливание перебора на специализированном оборудовании. Однако само наличие Argon2 не отменяет необходимость длинного и непредсказуемого мастер-пароля.

Утверждать, что облачные SaaS-сервисы не дают пользователю настраивать Argon2, неверно. Bitwarden позволяет выбрать Argon2id и настроить параметры его работы. Доступные параметры и значения могут зависеть от клиента и версии приложения, поэтому после изменения настроек стоит проверить, что они применились и согласованы между устройствами. KeePassXC также предлагает настройки параметров функции выработки ключа. У обеих систем решение о балансе между стойкостью и временем открытия базы связано с возможностями устройств: конфигурация, комфортная на компьютере, может оказаться медленной на телефоне.

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

Дополнительные факторы в KeePassXC и облачных сервисах

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

KeePassXC также поддерживает аппаратные ключи YubiKey в режиме challenge-response для дополнительного компонента защиты базы. Такой ключ имеет смысл, если владелец понимает, как он участвует в открытии хранилища и что делать при его потере. Аппаратный фактор не заменяет резервный план: без доступного ключа и предусмотренного способа восстановления можно самому лишиться доступа к записям.

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

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

Синхронизация данных: SaaS-инфраструктура против переноса файлов

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

Локальная база даёт выбор способа переноса. Файл можно копировать вручную или хранить в папке, которую синхронизирует сторонняя служба. Некоторые пользователи используют для этого Syncthing, Dropbox или Nextcloud. Такая схема может работать надёжно, но сама по себе не превращает один файл в полноценную совместную систему редактирования.

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

При этом считать, что программного объединения у локальных баз нет, тоже неправильно. KeePassXC поддерживает объединение баз данных. Это помогает свести изменения из разных копий, но не отменяет необходимости понять, какие именно версии объединяются, и проверить результат. Перед операцией разумно сохранить резервные копии обеих баз. Синхронизация файла и объединение записей внутри базы — разные процессы, и не каждый сторонний сервис синхронизации умеет выполнять вторую операцию.

Рабочая схема для локального хранилища требует нескольких привычек:

1. Не редактировать одну и ту же базу на нескольких устройствах одновременно, если способ синхронизации не рассчитан на такое использование.

2. Перед объединением конфликтующих версий сохранять отдельные копии исходных файлов.

3. После синхронизации проверять, что последние добавленные записи на месте и открываются.

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

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

Векторы угроз: сервер, клиент и само устройство

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

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

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

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

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

Инфостилер на заражённом устройстве опасен и для облачного сервиса, и для локального файла. Архитектура хранения не подменяет защиту устройства.

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

Гибридный вариант: собственный сервер синхронизации

Между SaaS и отдельным локальным файлом есть промежуточный путь. Bitwarden поддерживает самостоятельное развёртывание серверной части. Существует и Vaultwarden, сторонняя облегчённая реализация сервера, совместимая с клиентами Bitwarden. Это разные варианты, и их не стоит считать равнозначными по поддержке, требованиям и модели обслуживания.

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

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

Как соотнести модель с повседневным использованием

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

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

Self-hosted-вариант имеет смысл для пользователя, который готов поддерживать сервер, а не просто однажды его настроить. Такая схема оставляет автоматическую синхронизацию, но добавляет обслуживание инфраструктуры. Если обновления и резервные копии будут откладываться, собственный сервер способен стать менее надёжным звеном, чем крупный облачный сервис.

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

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