ANTICHAT - Менеджер паролей для security-инженера: threat model, архитектура и результаты аудитов

https://forum.antichat.xyz/attachmen...ca29da4fce.png

Откройте любой рейтинг «Лучшие менеджеры паролей 2025» - там сравнивают количество устройств, наличие VPN в комплекте и цену подписки. Для обычного пользователя хватит. Для security-инженера - мимо.

Когда я строил threat model для команды из 15 человек (часть работала с air-gapped системами), ни один такой обзор не ответил на три вопроса: где именно хранится ключ шифрования хранилища, что произойдёт при полной компрометации облачного провайдера и что показали независимые аудиты безопасности. Эта статья закрывает именно их - через моделирование угроз, архитектурный анализ и реальные результаты аудитов Cure53 и NCC Group.
Почему сравнение менеджеров паролей по фичам не работает для безопасности
Русскоязычные обзоры менеджеров паролей сводятся к одному паттерну: «вот пять продуктов, вот таблица с плюсами и минусами». Проблема в том, что для security-инженера критичны параметры, которых в этих таблицах просто нет:

Key escrow model - кто, кроме вас, может добраться до зашифрованного блоба и ключа расшифровки
KDF configuration - какая функция деривации ключа используется, сколько итераций
Audit trail - какие независимые аудиты проводились, кем, и что конкретно нашли
Компрометация серверной стороны - что именно получает атакующий при взломе серверов провайдера

Менеджер паролей для security-инженера - не про удобство автозаполнения. Это про гарантии, которые можно верифицировать через архитектуру, исходный код и аудиторские отчёты.
Threat model менеджера паролей: MITRE ATT&CK и реальные векторы атак
Прежде чем сравнивать продукты - определяем, от чего защищаемся. Менеджер паролей одновременно и высокоценная цель, и защитный механизм. В классификации MITRE ATT&CK есть отдельная техника - Password Managers (T1555.005, Credential Access) - она описывает извлечение учётных данных непосредственно из хранилищ паролей.
Векторы атак на менеджер паролей по MITRE ATT&CK
Полная картина техник, релевантных для атак на менеджеры паролей:

ТехникаIDТактикаКак применяется к менеджеру паролейPassword ManagersT1555.005Credential AccessПрямое извлечение данных из хранилища через доступ к файлу базы или API менеджераPassword CrackingT1110.002Credential AccessОфлайн-брутфорс мастер-пароля после получения зашифрованного хранилищаKeyloggingT1056.001Collection, Credential AccessПерехват мастер-пароля при вводеCredential API HookingT1056.004Collection, Credential AccessПерехват данных через хуки API расширения браузера или десктопного клиентаCredentials In FilesT1552.001Credential AccessПоиск незашифрованных экспортов, кэшей или дампов памяти процесса менеджераCompromise Software Supply ChainT1195.002Initial AccessКомпрометация обновления менеджера паролей или его расширения для браузераMFA Request GenerationT1621Credential AccessMFA 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 (хранится на устройстве). Для аутентификации используется протокол SRP (Secure Remote Password). 1Password исследует переход на OPAQUE, но на момент написания статьи SRP остаётся основным протоколом для большинства аккаунтов (актуальный статус миграции лучше проверять в официальной документации). Суть в том, что серверы 1Password никогда не видят ни мастер-пароль, ни Secret Key в открытом виде.

Шифрование хранилища - AES-256-GCM (по данным технической документации 1Password).

Что это означает на практике:

Даже при полном дампе серверов 1Password атакующий получает зашифрованные блобы, для расшифровки которых нужен и мастер-пароль, и Secret Key
Брутфорс мастер-пароля (T1110.002) недостаточен - нужен ещё 128-битный Secret Key
Обратная сторона: потеря Secret Key = потеря доступа к хранилищу. Никакого «сброса пароля»

Bitwarden: PBKDF2/Argon2id и серверная модель
Bitwarden использует классическую zero-knowledge архитектуру, но без дополнительного Secret Key. Ключ шифрования состоит только из мастер-пароля через KDF.

Bitwarden поддерживает два алгоритма KDF:

PBKDF2-SHA256 - дефолт для аккаунтов, созданных до 2023 года (можно переключить на Argon2id в настройках)
Argon2id - дефолт для новых аккаунтов с 2023 года, устойчив к брутфорсу на GPU/ASIC

Шифрование хранилища - AES-256-CBC с Encrypt-then-MAC (HMAC-SHA256). MAC проверяется до дешифрования, что предотвращает padding oracle атаки. Для сравнения: 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-файл или аппаратный ключ)

Обратная сторона: синхронизация между устройствами - ваша головная боль. В команде это решается через зашифрованный том на файловом сервере или через Git-репозиторий с шифрованными файлами. На air-gapped системах KeePassXC - по сути единственное практичное решение.
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"

;

}

}

Ограничение по IP-подсети VPN - обязательно. Менеджер паролей не должен торчать в публичный интернет без дополнительного слоя защиты.
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 lock

Для полноценного управления секретами инфраструктуры (ротация, TTL, динамические credentials) Bitwarden CLI недостаточен - тут нужен HashiCorp Vault или аналог. Для CI/CD-сценариев Bitwarden также предлагает Bitwarden Secrets Manager (

Код:

bws

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-сертификата, алерт при перезапуске контейнера

Корпоративный выбор менеджера паролей: сводная таблица

Критерий1PasswordBitwarden / VaultwardenKeePassXCМодель развёртыванияОблакоОблако или self-hostedЛокальноШифрованиеAES-256-GCMAES-256-CBC + HMACAES-256 или ChaCha20KDFPBKDF2-HMAC-SHA256 (мастер-пароль) + HKDF с Secret Key (128 бит)PBKDF2 или Argon2idArgon2d/Argon2idЗащита при утечке серверных данныхВысокая (двойная деривация)Средняя (зависит от силы мастер-пароля)Нерелевантно (нет сервера)Открытый исходный кодНетДаДаНезависимые аудитыNCC Group, Cure53 и др.Cure53EU-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 определяет инструмент, а не наоборот.