KeePass и KeePassXC в 2026 году: локальное хранение паролей и синхронизация базы между устройствами

KeePass или KeePassXC: что выбрать для локального хранения паролей

Выбор по умолчанию для локального хранения паролей в 2026 году - KeePassXC. Кроссплатформенный клиент с открытым исходным кодом, встроенным TOTP и интеграцией с браузерами, он одинаково работает на Linux, macOS и Windows, а вся база живёт в одном файле .kdbx, который не покидает ваши устройства, пока вы сами его куда-нибудь не положите.

KeePass 2.x - классический клиент под Windows, вокруг которого выросла большая экосистема плагинов: KeeOtp для одноразовых кодов, KeePassHttp для браузеров, десятки утилит для отчётов, импорта и печати аварийных копий. Цена этой гибкости: зависимость от .NET, ручная установка расширений и отсутствие официальной сборки под Linux и macOS.

Оба клиента читают один формат KDBX 4, поэтому переход между ними не требует конвертации и не запирает вас в одном приложении. Если вы ещё не определились с классом решения (локальное, облачное, self-hosted, PAM), начните с сравнения систем хранения паролей по модели доверия и стоимости.

Чем KeePassXC отличается от KeePass 2.x

Разница в браузерной интеграции критична для ежедневной работы. Протокол KeePassXC-Browser обменивается данными с расширением через локальный сокет, ассоциация подтверждается ключом, который пользователь видит на экране. KeePassHttp работал иначе: любой процесс на машине мог запросить у менеджера пароль по HTTP без шифрования. Плагин не развивается с 2016 года, и включать его стоит только для разовой миграции.

Не открывайте одну и ту же базу одновременно в KeePassXC и KeePass 2.x. Оба клиента перезаписывают файл целиком, и последний сохранивший затрёт изменения второго без предупреждения.

Совместимость формата KDBX и миграция между клиентами

KDBX 4 - открытый формат с документированной спецификацией. Его читают мобильные KeePassDX на Android, KeePassium и Strongbox на iOS, а также сторонние утилиты вроде kpcli для работы из терминала.

Порядок переезда из KeePass 2.x в KeePassXC занимает минуты: закройте базу, сделайте копию файла, откройте копию в KeePassXC (Database, Open Database), введите мастер-пароль и key-файл, затем сохраните. Пароли, группы, TOTP-секреты из KeeOtp и вложения переносятся штатно. Если база создана в KDBX 3.1, KeePassXC предложит обновить формат: это нужно, чтобы получить Argon2 и ChaCha20.

Обратная конвертация KDBX 4 в KDBX 3 выполнима, но бессмысленна: вы потеряете Argon2id и потоковый шифр внутренних полей, а вместе с ними и стойкость к подбору на GPU. Старые мобильные клиенты без поддержки Argon2 откроют базу только после понижения KDF до AES-KDF, что тоже снижает защиту. Перед любой миграцией копируйте .kdbx и key-файл на отдельный носитель.

Структура базы KDBX: что внутри и как это влияет на безопасность

Файл .kdbx состоит из двух частей: внешнего заголовка и зашифрованного тела. Во внешнем заголовке лежат сигнатура, версия формата, идентификатор шифра (AES-256 или ChaCha20), флаг сжатия, master seed, параметры KDF, вектор инициализации и ключ внутреннего потока. Эти значения нужны, чтобы клиент знал, чем расшифровывать базу, и они не секретны.

В KDBX 4 появился внутренний заголовок, который шифруется вместе с телом и хранит идентификатор и ключ потока для защищённых полей, а также список вложений. Тело - это XML-дерево групп и записей, сжатое gzip или deflate и зашифрованное целиком. Целостность проверяется побайтовыми блоками с HMAC-SHA-256: подмена файла или обрыв синхронизации приводят к ошибке при открытии, а не к молчаливой потере данных.

Шифры и KDF: AES-256, ChaCha20, Argon2

AES-256-CBC остаётся стандартным выбором: на x86-64 и современных ARM есть аппаратное ускорение AES-NI, и накладные расходы почти незаметны. ChaCha20 выигрывает там, где аппаратного AES нет или он медленный: старые Raspberry Pi, роутеры, встраиваемые платформы. Стойкость обоих вариантов сопоставима, разница только в скорости.

Стойкость базы к подбору определяет не шифр, а KDF. AES-KDF с раундами трансформации - устаревший механизм, он считается быстро и на GPU, поэтому нужен только для совместимости со старыми клиентами. Argon2id и Argon2d требуют памяти при каждом вычислении, из-за чего видеокарты теряют преимущество. Ориентиры для 2026 года: память 64-256 МиБ, итерации 3-10, параллелизм 2-4, соль 32 байта. KeePassXC по умолчанию подставляет сбалансированный профиль, KeePass 2.x использует Argon2d.

Итоговая рекомендация: KDBX 4, Argon2id, внешний шифр AES-256 на десктопе с AES-NI или ChaCha20 на слабом ARM. Смежные схемы шифрования дисков и ключей разобраны в материале о практических схемах шифрования данных на 2026 год.

Защищённые поля и метаданные записей

Пароли, TOTP-секреты и любые поля с флагом Protected шифруются отдельно, потоковым шифром внутреннего заголовка. В XML они лежат как base64-строка шифротекста и не появляются в открытом виде ни в файле, ни в дампе памяти при просмотре списка записей.

Остальные атрибуты (заголовок записи, логин, URL, заметка без флага Protected) хранятся в XML открытым текстом внутри зашифрованного тела. На диске они защищены, но при открытой базе доступны поиску, автозаполнению, браузерному расширению и любому, кто видит ваш экран. Токены API, приватные SSH-ключи и seed-фразы держите в защищённых полях или во вложениях, а не в обычной заметке. Отдельное предупреждение про key-файл: он не должен лежать в той же папке синхронизации, что и .kdbx, иначе оба фактора уезжают в облако одним пакетом.

Мастер-пароль и key-файл: как защитить базу от подбора

Схема защиты строится из двух независимых факторов. Мастер-пароль длиной от 20 символов (или фраза из 5-7 случайных слов) плюс key-файл: база открывается только при наличии обоих. Композитный ключ вычисляется как SHA-256 от хеша пароля, содержимого key-файла и служебных данных, после чего проходит через KDF с солью. Это значит, что украденный файл базы без key-файла не подбирается даже перебором словарей, а украденный key-файл без пароля бесполезен.

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

Как сгенерировать и хранить key-файл

1. В KeePassXC откройте Database, затем Database Security.
2. В разделе дополнительной защиты нажмите Add key file и выберите Generate.
3. Сохраните файл на съёмный носитель, а не в домашний каталог и не в папку синхронизации.
4. Второй экземпляр положите на офлайн-носитель в другом физическом месте.

Если нужен файл снаружи KeePassXC, подойдёт любая последовательность случайных байт длиной от 32 байт. Команды для генерации из терминала: openssl rand -out keyfile.key 64 либо head -c 64 /dev/urandom > keyfile.key. Файл формата XML, созданный KeePassXC, тоже работает и переносится между клиентами без изменений.

Аппаратный токен YubiKey умеет отдавать HMAC-SHA1-ответ на challenge, и KeePassXC поддерживает такую схему вместо key-файла. Токен нельзя скопировать, но потеря единственного ключа означает опять-таки потерю базы, поэтому в YubiKey Manager заранее программируют два носителя с одинаковым секретом и хранят их раздельно. Не отправляйте key-файл почтой, в мессенджерах и не коммитьте в Git: любой канал, проходящий через чужие серверы, для него закрыт.

Настройка KDF под своё железо

Параметры KDF подбирают по времени открытия базы, а не по таблице из интернета. Практический ориентир: 0,5-2 секунды на открытие - комфортно, до 3 секунд - приемлемо для базы с высокой ценностью содержимого. Если база открывается 10 секунд, пользователь начнёт искать обходные пути и держать пароли в браузере, что хуже любых настроек.

На настольном ПК с 16 ГБ памяти выставляйте Argon2id, 128-256 МиБ памяти, 8-10 итераций и параллелизм по числу ядер. На Raspberry Pi 4, тонком клиенте или старом ноутбуке снижайте память до 64 МиБ и итерации до 3-4: там каждый лишний мегабайт ощутим. Перед сменой параметров сделайте копию файла, потому что сбой записи при пересчёте KDF оставит вас с нечитаемым .kdbx.

Синхронизация базы KeePass между устройствами без облака

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

Nextcloud: self-hosted синхронизация с версионированием

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

Десктопный клиент Nextcloud синхронизирует папку в фоне, и это безопасный путь. Веб-редакторы и мобильные приложения с предпросмотром трогать .kdbx нельзя: попытка открыть файл в браузере или перезаписать его после скачивания на телефоне порождает копии вида conflicted copy. Такие файлы сливают в KeePassXC через Database, Merge From File, и только после проверки дубликатов удаляют.

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

Syncthing: P2P-синхронизация без сервера

Syncthing соединяет устройства напрямую, без промежуточного облака, и шифрует трафик TLS. Порядок настройки: установить клиент на все машины, сопрячь их по идентификаторам устройств, создать отдельную папку только под .kdbx, включить File Versioning в режиме Staggered с хранением 5-10 версий.

Конфликтов содержимого Syncthing не решает: при одновременной записи появится файл вида .sync-conflict-20260915-101500-ABCD1234.kdbx. Правило простое: одно устройство считается основным редактором, остальные работают в режиме чтения. Дополнительно добавьте в .stignore шаблон для key-файла, чтобы случайная копия не уехала на все узлы.

Git: хранение базы паролей в репозитории

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

Рабочий процесс выглядит так: одна рабочая копия, коммит и push после каждого изменения, никаких pull с конфликтом. Key-файл в репозитории не хранится. Для командной работы схема не подходит: разумнее выдать каждому специалисту отдельную базу, а общие сервисные учётки держать в self-hosted хранилище с аудитом.

Защита от конфликтов и слияние баз

Порядок действий, если база разошлась на двух устройствах:

1. Закройте базу на всех устройствах и дождитесь завершения синхронизации.
2. Определите, какая копия новее: сравните время изменения файла и журнал изменений, если вы его ведёте.
3. Откройте актуальную копию и выберите Database, Merge From File, указав конфликтный файл.
4. Просмотрите появившиеся дубликаты и удалите лишние вручную: слияние не всегда корректно отрабатывает удаления.
5. Сохраните результат, дайте синхронизации завершиться и только потом открывайте базу на втором устройстве.

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

Браузерные расширения и автозаполнение: настройка KeePassXC-Browser

Расширение KeePassXC-Browser ставится в Chrome, Chromium, Edge, Brave, Vivaldi и Firefox. Обмен идёт через native messaging и локальный сокет: пароль не попадает ни в сеть, ни в облако браузера. Установка KeePass 2.x с KeePassHttp для новых систем не рекомендуется: плагин передаёт учётные данные по незашифрованному HTTP любому локальному процессу, который умеет делать запросы.

Настройка native messaging и подключение базы

1. В KeePassXC: Tools, Settings, Browser Integration, включите Enable browser integration.
2. Отметьте в списке те браузеры, которые реально используете.
3. Установите расширение KeePassXC-Browser из магазина браузера.
4. Нажмите на иконку расширения и выберите Connect.
5. В появившемся окне KeePassXC проверьте имя подключения и сохраните ассоциацию.
6. В настройках расширения включите шифрование соединения и автозаполнение для выбранных сайтов.

Если расширение не видит менеджер, причина обычно в способе установки браузера. Snap- и flatpak-сборки Chromium ограничены в доступе к конфигурационным путям, и манифест native messaging не находится. Решение: установить браузер из deb или rpm-пакета либо выдать контейнеру доступ к каталогу KeePassXC. Вторая частая причина - база не разблокирована или вы работаете в другом профиле ОС.

Автозаполнение и защита буфера обмена

В расширении настраиваются две вещи: автозаполнение учётных данных по горячей клавише (по умолчанию Ctrl+Shift+F) и автоотправка формы. Автоотправку включайте только для второстепенных сервисов: на формах смены пароля, платёжных страницах и панелях администрирования она приводит к отправке устаревших данных или к случайным действиям.

Копирование пароля в буфер обмена удобно и опасно одновременно: буфер доступен любому процессу под вашим пользователем, а в сессиях RDP и на общих терминалах он синхронизируется с удалённой стороной. KeePassXC умеет очищать буфер автоматически: Tools, Settings, General, Clear clipboard after, значение 10 секунд. Для браузерной интеграции есть отдельный таймаут в разделе Browser Integration. Там, где это возможно, предпочитайте Auto-Type: он не оставляет пароль в буфере вовсе.

TOTP в KeePassXC: второй фактор внутри базы

KeePassXC генерирует одноразовые коды локально: ни телефон, ни сеть не нужны. Коды работают на десктопе, в браузере и в терминале, что удобно для серверов: команда keepassxc-cli show -t base.kdbx entry выдаёт код без графической оболочки.

Как добавить TOTP-секрет в запись

1. Откройте запись и выберите Entry, TOTP, Set up TOTP.
2. Вставьте секрет в Base32 или полный otpauth:// URI, выданный сервисом.
3. Проверьте, что сгенерированный код совпадает с эталонным, и сохраните запись.
4. Включите отображение колонки TOTP в списке записей и защиту секрета флагом Protected.

По умолчанию используется период 30 секунд, 6 цифр и алгоритм SHA-1. В otpauth:// URI можно явно задать period, digits и algorithm, и KeePassXC их поддержит. Секрет без флага Protected виден в открытом XML внутри базы, поэтому поле обязательно помечают защищённым. В KeePass 2.x та же задача решается плагином KeeOtp, который хранит seed в строковом поле записи.

Риски совмещения пароля и TOTP в одной базе

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

Для критичных сервисов (банк, root-доступ, админка домена, доступ к бэкапам) выносите второй фактор за пределы базы: отдельное устройство, аппаратный ключ FIDO2 там, где он поддерживается, или вторая база с собственным мастер-паролем. Резервные коды сервисов храните в защищённых полях или на бумаге, но не в той же записи, что пароль. Если выбираете между приложениями-аутентификаторами для критичных учёток, пригодится сравнение автономных 2FA-приложений с открытым исходным кодом.

Безопасность в работе: кейлоггеры, буфер обмена и блокировка базы

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

Two-Channel Auto-Type Obfuscation против кейлоггеров

Механизм Two-Channel Auto-Type Obfuscation разбивает ввод пароля на два канала: часть символов эмулируется как нажатия клавиш, часть проходит через буфер обмена и вставку. Клавиатурный шпион записывает неполную и перемешанную последовательность, восстановить пароль из неё нельзя. Включается в Tools, Settings, Auto-Type, флаг Use Two-Channel Auto-Type Obfuscation.

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

Автоочистка буфера обмена и блокировка базы

Рабочий набор настроек для десктопа:

• Clear clipboard after: 10 секунд, для паролей к особо чувствительным системам - 5 секунд.
• Lock database after inactivity: 5 минут.
• Lock on minimize и Lock on screen lock: включены, чтобы база закрывалась при сворачивании окна и блокировке сеанса ОС.
• Require password to reveal: подтверждение показа защищённого поля.
• Backup database file before saving: страховка от повреждения файла при записи.

Отключать эти таймауты ради удобства не стоит: разблокированная база читается любым процессом пользователя и видна в поиске окон. На серверах без графики используйте keepassxc-cli поверх шифрованного диска LUKS, храните базу вне общего каталога и блокируйте терминал при уходе. Сочетание CLI-доступа с шифрованием носителя описано в материале о клиентском и серверном шифровании для DevOps и администраторов.

Резервное копирование базы KeePass и восстановление

База паролей - единственный файл, потеря которого блокирует доступ ко всей инфраструктуре сразу. Резервных копий должно быть несколько, и они не должны зависеть от одного канала синхронизации.

Схема 3-2-1 для базы паролей

• Три копии: рабочая на ноутбуке, вторая на NAS или внешнем диске, третья на офлайн-носителе.
• Два разных носителя: например, NVMe в рабочей машине и USB-диск с шифрованием.
• Одна копия вне дома и вне офиса, в физически защищённом месте.

Key-файл хранится отдельно от .kdbx минимум в двух местах, причём одно из них офлайн. Экспорт в CSV или HTML для резервирования не подходит: это открытый текст со всеми паролями. Если экспорт всё же понадобился для разовой миграции, файл удаляют сразу после задачи, а не оставляют в загрузках.

Включите создание копии перед сохранением: Tools, Settings, General, Backup database file before saving, с отдельным каталогом на другом носителе. Комбинация версионирования Nextcloud или Syncthing и локальных копий даёт откат на любую точку за последние месяцы. Для архивации на NAS с ZFS используйте снапшоты: они исключают ситуацию, когда ошибка синхронизации затирает обе копии.

Проверка восстановления и типичные ошибки

Раз в квартал выполняйте учебное восстановление: возьмите копию, откройте её на машине, на которой рабочей базы нет, введите мастер-пароль и подставьте key-файл, проверьте несколько записей и убедитесь, что TOTP-коды генерируются.

Частые ошибки: бэкап без key-файла (самая опасная), копия в той же синхронизируемой папке, что и рабочая база, единственная копия в облаке без офлайн-дубля, мастер-пароль, известный только одному человеку без аварийного конверта в сейфе.

Типичные ошибки при переходе на KeePass и как их избежать

• Потеря key-файла. Решение: два носителя с копией, один из них офлайн, плюс отметка в чек-листе онбординга.
• Key-файл лежит рядом с базой в облаке. Решение: вынести его из синхронизируемой папки и проверить .stignore в Syncthing.
• Одновременная правка на двух устройствах. Решение: одно устройство-редактор, остальные только читают; перед открытием дожидаться конца синхронизации.
• Устаревший KeePassHttp. Решение: переход на KeePassXC-Browser и удаление плагина.
• Слабый мастер-пароль. Решение: 20+ символов или фраза из 5-7 случайных слов, хранимая офлайн.
• Отключённая автоочистка буфера. Решение: вернуть таймаут 10 секунд и блокировку базы через 5 минут простоя.
• TOTP и пароль критичного сервиса в одной записи. Решение: вынести второй фактор на отдельное устройство или в другую базу.
• Бэкап только в одну папку. Решение: схема 3-2-1 с офлайн-копией и ежегодной ротацией носителей.
• Понижение KDBX 4 до KDBX 3 ради старого клиента. Решение: обновить клиент или принимать снижение стойкости осознанно.

Чек-лист безопасной настройки KeePassXC

1. Установите KeePassXC и убедитесь, что версия актуальна.
2. Создайте базу в формате KDBX 4 с Argon2id.
3. Задайте мастер-пароль от 20 символов, сгенерированный или в виде длинной фразы.
4. Сгенерируйте key-файл и сохраните его отдельно от базы.
5. Подберите параметры KDF так, чтобы база открывалась за 0,5-2 секунды.
6. Настройте синхронизацию через Nextcloud, Syncthing или Git по схеме с одним редактором.
7. Включите браузерную интеграцию и проверьте автозаполнение на тестовом сайте.
8. Добавьте TOTP в нужные записи и пометьте секреты защищёнными полями.
9. Включите автоочистку буфера, блокировку по простою, при сворачивании и при блокировке ОС.
10. Настройте бэкапы 3-2-1 и проведите учебное восстановление на отдельной машине.

Начните с шагов 1-5 на одной машине: создайте базу, сохраните key-файл отдельно и проверьте открытие после перезагрузки. Синхронизацию и бэкапы подключайте только после того, как база гарантированно открывается локально, потому что восстановить доступ к разъехавшимся копиям без рабочего key-файла невозможно. Если позже понадобится перенести данные в другой менеджер, порядок действий описан в руководстве по переносу базы KeePass в Bitwarden, LastPass и Vaultwarden.