Password Managers в режиме offline only — это не просто «менеджер паролей без интернета». Это схема, где база с паролями хранится локально: на компьютере, телефоне или съёмном носителе. Нет облака, нет автоматической синхронизации, нет привычного «открыл на новом устройстве — всё уже там». Зато вы контролируете, где лежит база и кто к ней прикасался.
Такой вариант подходит, если вы не хотите доверять пароли облачному сервису, работаете с чувствительными данными или просто предпочитаете держать всё в своих руках. Но у offline-only есть обратная сторона: если сломался диск, потерялся телефон или вы неудачно скопировали файл базы, восстанавливаться придётся самому. Поэтому главная задача — не только выбрать менеджер, а выстроить понятный порядок хранения, резервных копий и переноса.
Офлайн защищает от утечки через облако, но не от кражи ноутбука, вредоносной программы на разблокированном устройстве и ошибки с резервной копией.
- Что значит offline only на практике
- Какой менеджер выбрать для offline-only
- Какую схему выбрать в зависимости от ситуации
- Как настроить базу с нуля
- Главное правило: одна актуальная копия
- Резервные копии: без них offline-only превращается в лотерею
- Как безопасно переносить базу без синхронизации
- Что делать с двухфакторной аутентификацией
Что значит offline only на практике
Есть два разных сценария, которые часто путают.
- Менеджер может работать без интернета. Например, вы открыли приложение в самолёте. Но сама база может лежать в облаке и синхронизироваться, когда появится сеть.
- База хранится только локально. Файл с паролями лежит на выбранном устройстве или носителе. Если вы хотите перенести его на другое устройство, вы делаете это вручную.
В теме offline only нас интересует второй вариант. То есть менеджер не должен сам отправлять базу в облако, а вы не должны случайно положить её в папку, которую синхронизирует iCloud Drive, Google Drive, Dropbox, OneDrive или другой сервис.
На практике это выглядит так: у вас есть зашифрованная база, например файл формата .kdbx, мастер-пароль для её открытия и, возможно, ключ-файл или аппаратный ключ. Менеджер открывает эту базу на устройстве, но не подтягивает свежие изменения с сервера. Если вы добавили новый пароль на ноутбуке, телефон сам об этом не узнает.
Какой менеджер выбрать для offline-only
Не начинайте с красивых функций. Для offline-only важнее другое: база должна храниться локально, приложение должно нормально работать на ваших устройствах, а формат базы не должен быть завязан на один сервис.
Часто для такой схемы смотрят на менеджеры, которые работают с локальными базами KeePass-совместимого формата: KeePassXC на Windows/macOS/Linux, KeePass 2.x на Windows, KeePassDX на Android, Strongbox на iOS/macOS. Это не означает, что нужен именно какой-то один продукт. Смысл в том, чтобы выбрать инструмент, который умеет хранить базу локально и не заставляет вас пользоваться облачной синхронизацией.
Перед выбором проверьте четыре вещи:
- можно ли хранить базу только на устройстве;
- есть ли экспорт и импорт без потери данных;
- работает ли приложение на всех устройствах, где база вам нужна;
- понятно ли, где именно приложение хранит файл базы и не попадает ли он в системную синхронизацию.
Какую схему выбрать в зависимости от ситуации
| Ситуация | Рабочая схема | Что получаете | На что обратить внимание |
|---|---|---|---|
| Один компьютер, пароли нужны в основном дома | Локальная база на компьютере + 2–3 зашифрованные резервные копии на разных носителях | Простая и контролируемая схема | Не храните все копии на одном диске и проверяйте восстановление |
| Ноутбук и телефон | Одна основная база, ручное копирование на телефон при необходимости | Доступ с двух устройств без облака | Не редактируйте две копии параллельно |
| Поездки и командировки | Временная копия базы на ноутбуке или телефоне перед поездкой | Доступ к паролям без постоянной связи с домашним компьютером | После поездки перенесите изменения обратно и удалите лишние временные копии |
| Высокие требования к изоляции | База на отдельном устройстве без постоянного доступа в интернет + резервные копии на съёмных носителях | Минимум риска утечки через сеть | Нужна строгая дисциплина с копиями и переносом |
| Нужен доступ в чрезвычайной ситуации | Резервная копия, ключ-файл и инструкция в надёжном физическом месте | Шанс восстановить доступ, если устройство потеряно | Не кладите мастер-пароль рядом с базой без понимания риска |
Как настроить базу с нуля
- Выберите место хранения. Создайте базу в локальной папке, которая не синхронизируется с облаком. Если приложение предлагает «синхронизировать через сервис», отключите это.
- Задайте сильный мастер-пароль. Для offline-only это ключ ко всему. Лучше использовать длинную фразу из нескольких случайных слов или пароль длиной от 16 символов. Не берите имена, даты, старые пароли и фразы из соцсетей.
- Оставьте нормальные настройки шифрования. Не нужно вручную выкручивать параметры так, чтобы база открывалась минуту. Выбирайте современные настройки, которые предлагает приложение: например, Argon2id, если оно доступно, или рекомендованный профиль KDF. На слабом телефоне слишком тяжёлые настройки могут стать проблемой.
- Решите, нужен ли ключ-файл. Ключ-файл усиливает защиту, но добавляет риск потери. Если база открывается только паролем плюс ключ-файл, потеря ключа означает потерю доступа. Храните его отдельно от базы, а не в той же папке.
- Импортируйте пароли аккуратно. Если переносите данные из браузера или другого менеджера, сначала импортируйте их в новую базу, проверьте записи, затем удалите промежуточные CSV-файлы. CSV с паролями — это открытая текстовая таблица, её нельзя оставлять на рабочем столе или в загрузках.
- Настройте автоблокировку. Включите блокировку базы после простоя, при переходе компьютера в сон и при закрытии приложения. На телефоне используйте биометрию только как удобство, а не как замену мастер-паролю.
- Включите защиту устройства. Офлайн-база бесполезна, если ноутбук открывается без пароля. Используйте штатное шифрование диска, надёжный пароль входа, блокировку экрана и обновления системы.
- Сразу сделайте резервную копию. Не после «как-нибудь потом», а сразу после создания базы. Скопируйте файл базы и ключ-файл, если он есть, на отдельный носитель и проверьте, что копия открывается.
Главное правило: одна актуальная копия
Без синхронизации самая частая проблема — не взлом, а путаница. Вы добавили пароль на ноутбуке, потом открыли старую копию на телефоне, потом сохранили её поверх новой. В итоге часть записей пропала или оказалась устаревшей.
Чтобы этого не было, договоритесь сами с собой: у базы есть одна актуальная версия. Остальные копии — это резервные или временные.
Порядок ручной работы может быть таким:
- Перед добавлением пароля на устройстве проверьте, что у вас последняя версия базы.
- Если база нужна на другом устройстве, скопируйте туда свежий файл вручную.
- Редактируйте только одну рабочую копию за раз.
- После изменений сделайте резервную копию.
- Если работали на временном устройстве, перенесите изменения обратно в основную базу.
- После переноса удалите лишние временные копии с устройства, которому не доверяете.
Если всё-таки появились две изменённые копии, не пытайтесь угадать, какая «правильнее». Откройте обе, сравните последние записи и перенесите недостающие данные в одну базу. После этого сохраните новую резервную копию и удалите старые конфликтные варианты.
Резервные копии: без них offline-only превращается в лотерею
В облачных менеджерах резервная копия часто спрятана где-то на стороне сервиса. В offline-only вы сами становитесь этим сервисом. Звучит неудобно, но это и есть цена контроля.
Нормальная схема резервного копирования для такой базы выглядит так:
- одна копия рядом с рабочей базой, чтобы быстро восстановиться после случайного удаления;
- одна копия на отдельном носителе, который не подключён к компьютеру постоянно;
- одна копия в другом физическом месте, например дома у близкого человека, в сейфе или на рабочем месте;
- отдельно сохранённый ключ-файл или запасной аппаратный ключ, если они используются;
- короткая инструкция восстановления для себя или доверенного человека.
Копии делайте не только по расписанию, но и после крупных изменений: переезд с другого менеджера, добавление большого числа аккаунтов, смена мастер-пароля, перенос на новый компьютер.
Раз в несколько месяцев откройте резервную копию на отдельном устройстве или в тестовой папке. Проверка должна быть простой: файл открывается, мастер-пароль подходит, ключ-файл на месте, нужные записи доступны. Если вы никогда не проверяли восстановление, считайте, что резервной копии у вас пока нет.
Как безопасно переносить базу без синхронизации
Ручной перенос не должен быть хаотичным. Лучше использовать один понятный способ и не менять его каждый раз.
- Съёмный носитель. Подойдёт флешка или внешний диск, но лучше не тот, который постоянно торчит в компьютере. Не подписывайте носитель словами вроде «пароли».
- Физическое подключение телефона. Если менеджер на телефоне хранит базу локально, скопируйте файл через кабель или файловый менеджер. После копирования проверьте, что база открывается.
- Локальная сеть. Можно передать файл вручную по сети, но не настраивайте автоматическую папку, которая будет постоянно синхронизировать базу. Иначе это уже не offline-only.
- Временная копия для поездки. Перед поездкой обновите базу, сделайте свежую резервную копию дома, скопируйте рабочую версию на дорожное устройство. После возвращения перенесите новые записи обратно.
Не отправляйте базу себе почтой «на всякий случай». Почтовый ящик — плохое место для зашифрованной, но всё же ценной базы. Если файл случайно попадёт не туда, вы добавите себе лишнюю проблему.
Что делать с двухфакторной аутентификацией
Многие менеджеры умеют хранить одноразовые коды 2FA вместе с паролями. Это удобно: открыли запись, скопировали пароль, рядом получили код. Но в offline-only схеме есть нюанс.
Если злоумышленник получит доступ к разблокированной базе, он может найти там и пароль, и код для входа. Для обычных аккаунтов это может быть приемлемым компромиссом. Для почты, банка, основного облачного хранилища и аккаунтов с ценными данными лучше держать 2FA отдельно: на другом устройстве, аппаратном ключе или в приложении-аутентификаторе,