Откройте любой рейтинг «Лучшие менеджеры паролей 2025» - там сравнивают количество устройств, наличие VPN в комплекте и цену подписки. Для обычного пользователя хватит. Для security-инженера - мимо.
Когда я строил threat model для команды из 15 человек (часть работала с air-gapped системами), ни один такой обзор не ответил на три вопроса: где именно хранится ключ шифрования хранилища, что произойдёт при полной компрометации облачного провайдера и что показали независимые аудиты безопасности. Эта статья закрывает именно их - через моделирование угроз, архитектурный анализ и реальные результаты аудитов Cure53 и NCC Group.
Почему сравнение менеджеров паролей по фичам не работает для безопасности
Русскоязычные обзоры менеджеров паролей сводятся к одному паттерну: «вот пять продуктов, вот таблица с плюсами и минусами». Проблема в том, что для security-инженера критичны параметры, которых в этих таблицах просто нет:- Key escrow model - кто, кроме вас, может добраться до зашифрованного блоба и ключа расшифровки
- KDF configuration - какая функция деривации ключа используется, сколько итераций
- Audit trail - какие независимые аудиты проводились, кем, и что конкретно нашли
- Компрометация серверной стороны - что именно получает атакующий при взломе серверов провайдера
Threat model менеджера паролей: MITRE ATT&CK и реальные векторы атак
Прежде чем сравнивать продукты - определяем, от чего защищаемся. Менеджер паролей одновременно и высокоценная цель, и защитный механизм. В классификации MITRE ATT&CK есть отдельная техника -
Ссылка скрыта от гостей
, Credential Access) - она описывает извлечение учётных данных непосредственно из хранилищ паролей.Векторы атак на менеджер паролей по MITRE ATT&CK
Полная картина техник, релевантных для атак на менеджеры паролей:| Техника | ID | Тактика | Как применяется к менеджеру паролей |
|---|---|---|---|
| Password Managers | T1555.005 | Credential Access | Прямое извлечение данных из хранилища через доступ к файлу базы или API менеджера |
| Password Cracking | T1110.002 | Credential Access | Офлайн-брутфорс мастер-пароля после получения зашифрованного хранилища |
| Keylogging | T1056.001 | Collection, Credential Access | Перехват мастер-пароля при вводе |
| Credential API Hooking | T1056.004 | Collection, Credential Access | Перехват данных через хуки API расширения браузера или десктопного клиента |
| Credentials In Files | T1552.001 | Credential Access | Поиск незашифрованных экспортов, кэшей или дампов памяти процесса менеджера |
| Compromise Software Supply Chain | T1195.002 | Initial Access | Компрометация обновления менеджера паролей или его расширения для браузера |
| MFA Request Generation | T1621 | Credential Access | MFA fatigue - бомбардировка пуш-уведомлениями для получения подтверждения авторизации |
Эта таблица и есть наш threat model. Хороший менеджер паролей должен иметь архитектурные ответы на каждый из этих векторов. Смотрим, как справляются три решения, которые я использую в разных контекстах.
Три модели угроз для трёх контекстов
Менеджер паролей для пентестера-одиночки и для корпоративной команды - разные инструменты под разные модели угроз:Персональное использование. Основная угроза - компрометация устройства (T1056.001, T1555.005) и фишинг мастер-пароля. Решение: KeePassXC с локальной базой + аппаратный ключ YubiKey.
Команда 5–50 человек. Основные угрозы - утечка при увольнении, шаринг паролей через мессенджеры (да, люди до сих пор кидают пароли в Telegram), supply chain (T1195.002). Решение: self-hosted Bitwarden (Vaultwarden) с LDAP-интеграцией.
CI/CD и инфраструктура. Основные угрозы - секреты в репозиториях (T1552.001), доступ сервисных аккаунтов. Решение: HashiCorp Vault для ротации секретов + Bitwarden CLI для отдельных credentials.
Архитектура менеджера паролей: где живёт ключ шифрования
Сравнение менеджеров паролей с точки зрения безопасности начинается с одного вопроса: где хранится ключ, который расшифровывает ваше хранилище? Ответ определяет, что именно получит атакующий при компрометации разных компонентов системы.1Password: Secret Key и двойная деривация ключа
Архитектура 1Password содержит элемент, уникальный для индустрии - Secret Key. Это 128-битный ключ, генерируемый локально на устройстве при создании аккаунта. На серверы 1Password он не передаётся никогда.Ключ шифрования хранилища состоит из двух факторов: мастер-пароля (знает пользователь) и Secret Key (хранится на устройстве). Для аутентификации используется
Ссылка скрыта от гостей
. 1Password исследует переход на OPAQUE, но на момент написания статьи SRP остаётся основным протоколом для большинства аккаунтов (актуальный статус миграции лучше проверять в официальной документации). Суть в том, что серверы 1Password никогда не видят ни мастер-пароль, ни Secret Key в открытом виде.Шифрование хранилища - AES-256-GCM (по данным технической документации 1Password).
Что это означает на практике:
- Даже при полном дампе серверов 1Password атакующий получает зашифрованные блобы, для расшифровки которых нужен и мастер-пароль, и Secret Key
- Брутфорс мастер-пароля (T1110.002) недостаточен - нужен ещё 128-битный Secret Key
- Обратная сторона: потеря Secret Key = потеря доступа к хранилищу. Никакого «сброса пароля»
Bitwarden: PBKDF2/
Ссылка скрыта от гостей
и серверная модель
Bitwarden использует классическую zero-knowledge архитектуру, но без дополнительного Secret Key. Ключ шифрования состоит только из мастер-пароля через KDF.Bitwarden поддерживает два алгоритма KDF:
- PBKDF2-SHA256 - дефолт для аккаунтов, созданных до 2023 года (можно переключить на Argon2id в настройках)
- Argon2id - дефолт для новых аккаунтов с 2023 года, устойчив к брутфорсу на GPU/ASIC
Ссылка скрыта от гостей
. Для сравнения: 1Password использует AES-256-GCM (AEAD), где аутентификация встроена в режим шифрования.Ключевое отличие от 1Password: при компрометации серверов атакующий получает зашифрованные хранилища, и для расшифровки нужен только мастер-пароль. Нет второго фактора деривации. Это делает выбор сильного мастер-пароля и правильного KDF критически важным.
Зато у Bitwarden - открытый исходный код и возможность self-hosting. Вы контролируете, где физически лежат зашифрованные блобы, и можете аудировать серверный код. Для организаций, где нормативные требования запрещают передачу данных третьим сторонам, это решающий аргумент.
KeePassXC: полностью локальное хранилище
KeePassXC хранит всё в локальном файле формата KDBX (версия 4). Никакого облака, никакого сервера, никакой синхронизации «из коробки».Поддерживаемые алгоритмы шифрования - AES-256 или ChaCha20. KDF - Argon2d или Argon2id с настраиваемыми параметрами (итерации, память, параллелизм).
С точки зрения threat model - самая простая архитектура:
- Нет серверной стороны - нечего ломать на сервере
- Нет supply chain для серверного компонента (T1195.002 ограничивается клиентом)
- Атакующему нужен физический доступ к файлу
.kdbx+ мастер-пароль (+ опционально key-файл или аппаратный ключ)
Bitwarden vs 1Password: безопасность при компрометации
Абстрактное «всё зашифровано» не отвечает на вопрос «насколько я защищён?». Разберём три конкретных сценария.Сценарий 1: взлом облачного провайдера
Именно это произошло с LastPass в 2022 году - атакующие добрались до облачного хранилища и утащили зашифрованные хранилища пользователей. Классика жанра.1Password. Атакующий получает зашифрованные блобы. Для расшифровки нужен мастер-пароль + Secret Key (128 бит). Офлайн-брутфорс практически невозможен - даже слабый мастер-пароль защищён вторым фактором.
Bitwarden (облако). Атакующий получает зашифрованные блобы. Для расшифровки нужен только мастер-пароль. Если пользователь выбрал слабый пароль и стоит PBKDF2 с низким числом итераций - риск реален.
Bitwarden (self-hosted). Атакующему нужно сначала скомпрометировать ваш сервер, а не облако Bitwarden. Периметр полностью под вашим контролем.
KeePassXC. Сценарий нерелевантен - нет облака.
Сценарий 2: компрометация устройства
Если атакующий получил доступ к устройству с разблокированным менеджером паролей (T1555.005), разница между продуктами минимальна - все три одинаково уязвимы. Данные в памяти процесса доступны. Тут уже всё равно, какой менеджер стоит.Различие - в деталях:
- 1Password - автоматическая блокировка по таймауту и после закрытия крышки
- KeePassXC - тонкая настройка автоблокировки и очистка буфера обмена (по умолчанию 10 секунд)
- Bitwarden - поддержка PIN для быстрой разблокировки, но ключ сидит в памяти процесса на протяжении всей сессии
Сценарий 3: утечка мастер-пароля
Перехват мастер-пароля через кейлоггер (T1056.001) или фишинг:- 1Password: мастер-пароль без Secret Key бесполезен. Атакующему нужен физический доступ к устройству, где хранится Secret Key
- Bitwarden: мастер-пароль достаточен для расшифровки хранилища (при наличии зашифрованного блоба). MFA защищает от авторизации, но не от офлайн-брутфорса уже полученного блоба
- KeePassXC: мастер-пароль + доступ к файлу
.kdbx. Если используется key-файл - нужен и он
Аудит безопасности менеджера паролей: Cure53, NCC Group и open source
Маркетинговое «мы прошли независимый аудит» - красивый фантик. Без конкретики: кто проводил, какой scope, что нашли, что исправили - это пустые слова.Bitwarden: аудиты Cure53
Bitwarden регулярно заказывает аудиты у Cure53 - одной из наиболее уважаемых европейских компаний в области аудита безопасности. Аудиты покрывают клиентские приложения, серверную часть и браузерные расширения. Результаты публикуются на сайте Bitwarden. Аудит Cure53 2023 года выявил ряд findings низкой и средней severity, связанных с обработкой данных в браузерных расширениях и клиентских приложениях; все проблемы, по заявлению Bitwarden, были исправлены. Полные отчёты - на bitwarden.com/compliance.Открытый исходный код (GitHub) означает, что помимо формальных аудитов любой исследователь может залезть в криптографическую реализацию и проверить руками. Это не замена профессиональному аудиту, но существенно увеличивает шансы найти баг.
На практике это даёт вот что: вы можете самостоятельно верифицировать, что код на сервере (или в Vaultwarden) делает то, что заявлено. Для self-hosted сценария - критически важно.
1Password: программа аудитов и bug bounty
1Password проходил аудиты у нескольких независимых компаний, включая NCC Group, Cure53 и других. Плюс программа bug bounty через Bugcrowd.Исходный код 1Password закрыт. Вы доверяете не коду, а аудиторам и процессу. Для многих корпоративных клиентов SOC 2 Type II и регулярные аудиты от признанных компаний - достаточное основание. Лично я предпочитаю иметь возможность заглянуть под капот, но понимаю, почему enterprise выбирает иначе.
Менеджер паролей open source: преимущества для аудита
Открытый исходный код - не гарантия безопасности, но гарантия верифицируемости. Для security-инженера разница принципиальна:| Параметр | Open source (Bitwarden, KeePassXC) | Closed source (1Password) |
|---|---|---|
| Верификация криптографии | Самостоятельно | Только через аудит |
| Supply chain контроль | Можно собрать из исходников | Доверие к бинарнику вендора |
| Аудит сообществом | Непрерывный | Отсутствует |
| Формальные аудиты | Cure53 (Bitwarden) | NCC Group, Cure53 и др. (1Password) |
| Реакция на уязвимости | Публичные коммиты с фиксами | Чёрный ящик, changelog |
Zero-knowledge менеджер паролей: маркетинг vs архитектура
Термин «zero-knowledge» используется почти каждым вендором менеджеров паролей. На заборе тоже написано - разберёмся, что за этим стоит в реальности.Zero-knowledge (в контексте менеджера паролей) = провайдер не имеет технической возможности расшифровать ваши данные. Шифрование и дешифрование происходит исключительно на клиенте. На сервер уходит только зашифрованный блоб.
Все три рассмотренных решения реализуют zero-knowledge корректно. Но нюанс: zero-knowledge не защищает от компрометации клиента. Если атакующий контролирует ваше устройство (T1555.005, T1056.004), zero-knowledge архитектура серверной стороны не спасёт - данные расшифровываются локально и доступны в памяти процесса.
И ещё: zero-knowledge означает невозможность «сброса пароля» через провайдера. Потеряли мастер-пароль (и Secret Key в случае 1Password) - данные потеряны навсегда. Это не баг, а фундаментальное свойство архитектуры.
Практика: self-hosted менеджер паролей для команды
Self-hosted Bitwarden закрывает сразу несколько требований: контроль над данными, независимость от облачного провайдера, интеграция с корпоративной инфраструктурой. На практике рекомендую Vaultwarden - альтернативную реализацию серверной части Bitwarden на Rust, совместимую с официальными клиентами. Работает шустро, ест мало ресурсов, и для команды до 50 человек - за глаза.Развёртывание Vaultwarden через Docker Compose
YAML:
# docker-compose.yml - минимальная production-конфигурация Vaultwarden
version: "3.8"
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
# Отключаем регистрацию после создания аккаунтов команды
SIGNUPS_ALLOWED: "false"
# Включаем admin-панель с токеном (сгенерировать: openssl rand -base64 48)
ADMIN_TOKEN: "${ADMIN_TOKEN}"
# WebSocket для live-синхронизации (встроен в основной порт с Vaultwarden 1.29+)
# WEBSOCKET_ENABLED больше не требуется в версиях 1.29+
# TLS-терминация выполняется на reverse proxy (Nginx), Vaultwarden работает по HTTP
# Ограничение неудачных попыток входа
LOGIN_RATELIMIT_MAX_BURST: 5
LOGIN_RATELIMIT_SECONDS: 60
volumes:
- ./vw-data:/data
ports:
- "127.0.0.1:8080:80"
# Порт 3012 не нужен в Vaultwarden 1.29+ - WebSocket работает через основной портSIGNUPS_ALLOWED: false предотвращает несанкционированную регистрацию, rate limiting защищает от брутфорса, привязка к 127.0.0.1 - прямой доступ только через reverse proxy.Reverse proxy с Nginx
NGINX:
# /etc/nginx/sites-available/vaultwarden
server {
listen 443 ssl http2;
server_name vault.internal.example.com;
ssl_certificate /etc/letsencrypt/live/vault.internal.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vault.internal.example.com/privkey.pem;
# Современные TLS-настройки
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# Ограничение доступа по IP (только VPN-подсеть)
allow 10.8.0.0/24;
deny all;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# WebSocket для live sync (Vaultwarden 1.29+ - через основной порт)
location /notifications/hub {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}Bitwarden CLI для интеграции с CI/CD
Для автоматизации в CI/CD-пайплайнах Bitwarden предоставляет CLI-клиент:
Bash:
# Авторизация через API-ключ (безопаснее, чем мастер-пароль в переменных)
export BW_CLIENTID="user.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
export BW_CLIENTSECRET="yyyyyyyyyyyyyyyyyyyyyyyy"
bw login --apikey
# Разблокировка сессии
# ВНИМАНИЕ: BW_PASSWORD в env - риск утечки через /proc, логи CI. Используйте masked variables.
# --passwordenv доступен с CLI 2023.1.0+. Для production рекомендуется bws (Secrets Manager).
export BW_SESSION=$(bw unlock --passwordenv BW_PASSWORD --raw)
# Получение конкретного секрета по UUID (надёжнее, чем по имени)
# UUID можно узнать: bw list items --search "production-db" | jq -r '.[0].id'
DB_PASSWORD=$(bw get password "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")
# Использование в скрипте деплоя
deploy_app --db-password "$DB_PASSWORD"
# Блокировка после использования
bw lockbws CLI), заточенный под машинный доступ к секретам. Обычный bw решает задачу «достать credential для единоразового использования в пайплайне», но bws - рекомендуемый инструмент для автоматизации.Hardening checklist для Vaultwarden
После развёртывания - обязательные шаги:- Отключите регистрацию (
SIGNUPS_ALLOWED=false) сразу после создания всех аккаунтов - Настройте автоматическое резервное копирование директории
vw-data(там SQLite-база и вложения) - Включите fail2ban для мониторинга неудачных попыток входа - Vaultwarden пишет логи в стандартный stdout
- Настройте 2FA для всех пользователей - обязательно через TOTP или аппаратный ключ (WebAuthn/FIDO2)
- Ограничьте доступ admin-панели отдельным IP или отключите после настройки (
ADMIN_TOKEN= пустая строка) - Настройте мониторинг: uptime check, проверка срока SSL-сертификата, алерт при перезапуске контейнера
Корпоративный выбор менеджера паролей: сводная таблица
| Критерий | 1Password | Bitwarden / Vaultwarden | KeePassXC |
|---|---|---|---|
| Модель развёртывания | Облако | Облако или self-hosted | Локально |
| Шифрование | AES-256-GCM | AES-256-CBC + HMAC | AES-256 или ChaCha20 |
| KDF | PBKDF2-HMAC-SHA256 (мастер-пароль) + HKDF с Secret Key (128 бит) | PBKDF2 или Argon2id | Argon2d/Argon2id |
| Защита при утечке серверных данных | Высокая (двойная деривация) | Средняя (зависит от силы мастер-пароля) | Нерелевантно (нет сервера) |
| Открытый исходный код | Нет | Да | Да |
| Независимые аудиты | NCC Group, Cure53 и др. | Cure53 | EU-FOSSA аудит, публичный код |
| SSO/LDAP интеграция | Нативно (бизнес-план) | Через Vaultwarden (ограниченно) | Нет |
| CLI для автоматизации | Да | Да | Да (keepassxc-cli) |
| Работа в air-gapped среде | Нет | Да (self-hosted в изолированной сети) | Да (нативно) |
| Стоимость для команды | Платная подписка | Бесплатно (Vaultwarden) | Бесплатно |
Какой менеджер паролей выбрать security-инженеру
«Зависит от контекста» - банально, но это единственный честный ответ. Вот конкретная схема, которую я использую:1Password Teams - когда в команде есть нетехнические сотрудники, важен отполированный UX и бюджет позволяет. Secret Key компенсирует слабость мастер-паролей менее технически грамотных коллег (а они будут слабыми, не обольщайтесь). Travel Mode незаменим при пересечении границ с ноутбуком, содержащим чувствительные данные.
Self-hosted Bitwarden (Vaultwarden) - для технической команды, которая хочет полного контроля. Открытый код позволяет верифицировать безопасность. Идеально для организаций с требованиями к локализации данных или регуляторными ограничениями на облачные сервисы. Обратная сторона - вы сами отвечаете за доступность, бэкапы и обновления. Если ваш Vaultwarden лёг в пятницу вечером - это ваша проблема.
KeePassXC - для air-gapped систем, хранения наиболее критичных credentials (root-пароли инфраструктуры, recovery codes) и личного использования. Отсутствие сетевого компонента - не ограничение, а основное преимущество в определённых threat model.
Комбинированный подход на практике выглядит так: 1Password или Bitwarden для ежедневной работы команды, KeePassXC для критических секретов в офлайн-хранилище, HashiCorp Vault для инфраструктурных секретов с автоматической ротацией.
Одно решение не закрывает все сценарии. Ключевая ошибка - пытаться унифицировать инструмент вместо того, чтобы сопоставить каждый сценарий с подходящей архитектурой. Проверьте, какой KDF стоит у вашего текущего менеджера паролей прямо сейчас. Если там PBKDF2 с дефолтными итерациями - переключите на Argon2id, пока не стало поздно. Threat model определяет инструмент, а не наоборот.
Последнее редактирование модератором:
