В 2022 году серверы LastPass скомпрометировали, и атакующие вынесли зашифрованные хранилища пользователей - целиком. Пароли внутри были зашифрованы на стороне клиента, но URL сайтов, имена записей и метаданные лежали в открытом виде. В следующие месяцы криптосообщество зафиксировало кражи активов у тех, чьи мастер-пароли оказались достаточно слабыми для офлайн-перебора. Этот postmortem - не про "плохой менеджер паролей". Он про конкретные архитектурные решения: какой KDF, сколько итераций, что именно шифруется, а что - нет. Разберём архитектуру хранения паролей в четырёх принципиально разных классах менеджеров и покажем, почему при одинаковом маркетинговом "AES-256" реальная стойкость отличается на порядки.
Критерии отбора: почему именно эти четыре класса
Четыре архитектурно различных подхода - не четыре "лучших менеджера", а четыре разные философии хранения секретов:- KeePass/KeePassXC - локальный файл-база, без облачной синхронизации из коробки. Открытый исходный код. Чисто офлайн-модель. Ты сам решаешь, где лежит
.kdbx. - Bitwarden - облачный менеджер с zero-knowledge архитектурой и опцией self-hosting. Открытый исходный код. Облачная open-source модель.
- 1Password - облачный менеджер с проприетарной моделью Two-Secret Key Derivation (2SKD). Закрытый код, но публичные whitepaper и независимые аудиты. Модель с дополнительным секретом устройства.
- Браузерные менеджеры (Chrome, Firefox, Safari/iCloud Keychain) - встроенные в браузер, интеграция с OS keychain. Безопасность привязана к учётной записи ОС. И вот тут начинается самое интересное.
KDF под микроскопом: как мастер-пароль становится ключом шифрования
Мастер-пароль - строка произвольной длины. AES-256 требует ключ ровно 256 бит. Между ними стоит Key Derivation Function - и именно здесь проходит граница между "взломать за час на GPU-ферме" и "взломать за столетие".
PBKDF2 - проверенный, но уязвимый к GPU-перебору
PBKDF2-HMAC-SHA256 - стандарт из RFC 8018. Принцип прост: многократное применение HMAC с уникальной солью. Критический параметр - количество итераций.После инцидента с LastPass Bitwarden поднял дефолт до 600 000 итераций на клиенте и добавил поддержку Argon2id как альтернативы. 1Password использует PBKDF2 с 650 000 итераций (согласно актуальному whitepaper), но в связке с Secret Key (128 бит дополнительной энтропии) - и это кардинально меняет модель угроз. LastPass на момент компрометации держал дефолт 100 100 итераций для новых аккаунтов, а у старых значение могло быть 5 000 или даже 1 - без принудительной миграции. Вдумайтесь: одна итерация.
Проблема PBKDF2: он отлично параллелизуется на GPU и ASIC. На стенде с NVIDIA RTX 4090
hashcat в режиме перебора PBKDF2-HMAC-SHA256 хэшей с 600 000 итераций выдаёт порядка сотен - низких тысяч попыток в секунду (зависит от конкретных параметров KDF). Для 8-символьного пароля из строчных латинских букв - перебор за дни или недели. Техника Password Cracking (T1110.002, Credential Access) - именно так атакующие работают с украденными vault-файлами.Argon2id - память как фактор защиты
Argon2 - победитель Password Hashing Competition 2015 года. Ключевое отличие от PBKDF2: помимо вычислительной сложности, требует выделения фиксированного объёма оперативной памяти. Argon2id - гибрид, устойчивый и к side-channel атакам, и к GPU-перебору.KeePass 2.x использует Argon2d, KeePassXC (с версии 2.6.0) - Argon2id как дефолтный KDF для новых баз KDBX 4.0. Параметры настраиваемые: итерации, память (в МБ), параллелизм. Bitwarden добавил Argon2id как опцию - дефолт: 3 итерации, 64 МБ памяти, 4 потока.
Почему это критично: GPU имеют высокую вычислительную мощность, но ограниченную быструю память на ядро. Argon2id с 64 МБ делает массовый перебор на GPU-кластере экономически нецелесообразным - каждый поток перебора требует выделения этого объёма. Грубо говоря, ферма из десяти RTX 4090 упирается не в CUDA-ядра, а в VRAM.
Браузерные менеджеры - KDF вне контроля пользователя
Chrome хранит пароли в SQLite-базеLogin Data, шифруя значения через OS API: DPAPI на Windows, Keychain на macOS. Мастер-пароля в классическом понимании нет - ключ привязан к сессии пользователя ОС. Firefox использует NSS с опциональным Primary Password, но по умолчанию он отключён. То есть по дефолту - ничего.Если атакующий получил активную сессию Windows (через RDP, физический доступ, малварь), DPAPI-защита Chrome снимается вызовом
CryptUnprotectData без дополнительных секретов. Это прямой вектор для техники Credentials from Web Browsers (T1555.003, Credential Access) - одна из самых популярных техник в арсенале стилеров (RedLine, Raccoon, Vidar). Одна строчка кода - и все пароли в открытом виде.Иерархия ключей: почему архитектура важнее алгоритма
Один и тот же AES-256 защищает данные совершенно по-разному в зависимости от того, как организована иерархия ключей. Алгоритм - это замок. Иерархия ключей - это то, сколько дверей и в каком порядке.
KeePass использует плоскую модель: Composite Key (мастер-пароль + опциональный ключевой файл + привязка к Windows-аккаунту) через KDF превращается в единственный ключ, которым шифруется вся база KDBX (AES-256-CBC или ChaCha20). Смена мастер-пароля - полное перешифрование файла. Нет возможности дать коллеге доступ к одной папке, не раскрывая остальные. Для SOC это упрощает мониторинг: файл
.kdbx не покидает периметр (если не синхронизирован вручную), любое обращение к нему процессом, отличным от KeePass.exe/KeePassXC.exe, - алерт. Техника: Credentials In Files (T1552.001, Credential Access).Bitwarden реализует двухуровневую схему. Из мастер-пароля и email (как соли) через KDF вычисляется Master Key. Им расшифровывается Symmetric Key - случайно сгенерированный при регистрации, хранится на сервере в зашифрованном виде. Symmetric Key шифрует отдельные записи vault. Для аутентификации из Master Key вычисляется Master Password Hash (дополнительный проход PBKDF2 с 1 итерацией), который отправляется на сервер, где хранится его bcrypt-хэш. Даже при компрометации серверной базы атакующий получает bcrypt-хэш от производной - не сам ключ шифрования. При смене мастер-пароля перешифровывается только Symmetric Key, не весь vault. Элегантно.
1Password использует Two-Secret Key Derivation (2SKD) - и это архитектурно сильнее всех остальных в сценарии серверной компрометации. Ключ шифрования вычисляется из мастер-пароля И Secret Key - случайно сгенерированной 128-битной строки, которая создаётся при регистрации и хранится только на устройствах пользователя. Серверы 1Password этот Secret Key не знают. Даже если серверы скомпрометированы и атакующий получил зашифрованные vault'ы, перебор мастер-пароля бесполезен без Secret Key. 128 бит дополнительной энтропии делают brute-force нереалистичным. Обратная сторона: потеря Secret Key = потеря данных без возможности серверного восстановления. 1Password рекомендует распечатать Emergency Kit и хранить в физическом сейфе. Бумага в сейфе как последний рубеж обороны - в 2025 году звучит иронично, но работает.
Браузерные менеджеры привязывают ключ к сессии ОС. Chrome через DPAPI, Firefox через NSS. CVE-2019-11733 (CVSS 9.8, CWE-287 - Improper Authentication) показала критический дефект Firefox: пароли копировались в буфер обмена через контекстное меню без повторного ввода мастер-пароля, если он вводился ранее в той же сессии (Firefox < 68.0.2). Прямой вектор для Clipboard Data (T1115, Collection).
Сравнение архитектур шифрования менеджеров паролей
| Критерий | KeePass/KeePassXC | Bitwarden | 1Password | Chrome / Firefox |
|---|---|---|---|---|
| KDF по умолчанию | Argon2d (KeePass) / Argon2id (KeePassXC) | PBKDF2 600K итераций (Argon2id - опция) | PBKDF2 650K + Secret Key 128 бит | DPAPI / NSS (привязка к ОС) |
| Шифрование vault | AES-256-CBC или ChaCha20 | AES-256-CBC | AES-256-GCM | AES-256 через OS API |
| Zero-knowledge | Да (сервера нет) | Да | Да (усилено 2SKD) | Нет (при sync через аккаунт) |
| Иерархия ключей | Плоская: 1 ключ = вся база | Двухуровневая: Master Key, Symmetric Key | Двухуровневая + Secret Key | Плоская: сессия ОС = ключ |
| Защита при утечке сервера | Не применимо | Зависит от стойкости мастер-пароля + KDF | Защищено Secret Key | Зависит от аккаунта Google/Mozilla |
| Открытый исходный код | Да | Да | Нет (публичные аудиты) | Частично (Chromium, NSS) |
| Корпоративное управление | Нет | Bitwarden Organizations | 1Password Business | GPO / MDM |
| Синхронизация | Ручная (Syncthing, Dropbox) | Встроенная (облако/self-host) | Встроенная (облако) | Через аккаунт браузера |
Модель угроз и detection: что мониторить в SOC
Для SOC-аналитика менеджер паролей - не только объект защиты, но и вектор атаки. MITRE ATT&CK выделяет технику Password Managers (T1555.005, Credential Access): извлечение credentials из менеджера на скомпрометированном хосте.Detection по классам менеджеров
KeePass (.kdbx файлы): обращение к файлам*.kdbx процессами, отличными от KeePass/KeePassXC. В EDR (CrowdStrike Falcon, Elastic 8.x+, SentinelOne) - FileRead-событие с фильтром по расширению. Запуск keepass2john - атакующий извлекает хэш для офлайн-перебора (T1110.002). Копирование .kdbx на съёмные носители - T1552.001.Bitwarden (self-hosted): аномальное количество запросов к
/api/sync. Bitwarden Event Logs: неудачные аутентификации, вход с новых IP. Для 1Password Business - 1Password Events API с интеграцией в SIEM.Браузеры: обращение к
Login Data (Chrome) или logins.json/key4.db (Firefox) нестандартными процессами - классический IOC стилеров. Вызовы CryptUnprotectData из нетипичных процессов - для частичного покрытия включается аудит DPAPI Activity (события 4692–4695 для операций с master key), но штатный аудит не фиксирует каждый вызов CryptUnprotectData; полное покрытие требует прямого подключения ETW-провайдера Microsoft-Windows-Crypto-DPAPI через инструмент вроде SilkETW. Кейлоггинг (T1056.001, Credential Access) при вводе мастер-пароля - мониторинг SetWindowsHookEx через EDR.Insider threat: легитимный сотрудник с доступом к организационному vault Bitwarden/1Password экспортирует базу. Detection: логирование событий export/download в Events API, корреляция с нетипичным временем (ночные часы, выходные) и объёмом выгруженных записей. Сотрудник, экспортирующий 500 записей в 2 ночи в пятницу - это не "забыл пароль от Wi-Fi".
YAML:
title: Suspicious Access to Password Manager Vault Files
logsource:
category: file_event # Sysmon EventID 11 (FileCreate); для file-read нужен EDR с соответствующей телеметрией
product: windows
detection:
selection:
TargetFilename|endswith:
- '.kdbx'
- 'Login Data'
- 'logins.json'
- 'key4.db'
filter:
Image|endswith:
- 'KeePass.exe'
- 'KeePassXC.exe'
- 'chrome.exe'
- 'firefox.exe'
condition: selection and not filter
level: highЧеклист аудита менеджера паролей в корпоративной среде
После аудита десятка корпоративных внедрений менеджеров паролей за последние два года скажу прямо: основная проблема - не выбор между 1Password и Bitwarden. Основная проблема - браузерные менеджеры, которые никто не отключает. В реальных проектах раз за разом одна и та же картина: GPO не содержит запрета на сохранение паролей в Chrome, при этом корпоративный Bitwarden развёрнут и лицензирован. Сотрудники продолжают сохранять критические credentials в браузере - потому что это на два клика быстрее. Стилер на одной рабочей станции - и вся архитектура с Argon2id и zero-knowledge оказывается бессмысленной.
В 2025 году единственный надёжный выбор KDF - Argon2id; в Bitwarden его нужно включить вручную в настройках с параметрами не ниже 64 МБ памяти. PBKDF2 с любым количеством итераций проигрывает GPU-кластеру с бюджетом, доступным средней ransomware-группировке. Модель 2SKD от 1Password архитектурно сильнее всех рассмотренных, потому что снимает зависимость от стойкости мастер-пароля при серверной компрометации - но за это платишь управляемостью: потеря Secret Key означает потерю данных без восстановления, и корпоративному SOC нужен процесс хранения Emergency Kit не менее строгий, чем для корневых сертификатов PKI.
Проверьте свою инфраструктуру по чеклисту выше. Если в SIEM нет правил на обращения к vault-файлам и DPAPI-события - на форуме codeby.net коллеги разбирают рабочие Sigma-правила и подходы к detection T1555 в тематическом треде.
Последнее редактирование модератором:
