Я не рекомендую Bitwarden

Четыре года назад Marius написал руководство по запуску vaultwarden в качестве бэкенда для bitwarden на защищённой OpenBSD. Эта публикация - продолжение: он больше не рекомендует Bitwarden и подробно объясняет причины, разбирая архитектуру, лицензирование, UX и череду из пяти инцидентов безопасности. Статья завершается концепцией разделения секретов по принципу "разделяй и властвуй", в которой автор полностью отказывается от модели единого хранилища.

Влияние инвесторов

В 2022 году Bitwarden привлёк $100M от PSG growth equity (и Battery Ventures). Marius рассматривает это как предсказуемый переломный момент: open-source продукт + инвестор, требующий возврата инвестиций = путь к извлечению ренты, где бесплатный софт служит приманкой, а настоящим продуктом становится SaaS-подписка. Эпизод с лицензированием SDK в конце 2024 года служит тому подтверждением: @bitwarden/sdk-internal вышел с пунктом, запрещающим использование "с программным обеспечением, отличным от Bitwarden (включая несовместимые реализации Bitwarden)". После возмущения сообщества и статьи на Phoronix компания Bitwarden назвала это ошибкой сборки пакета и перелицензировала код под GPLv3. Формально вопрос закрыт, но подход показателен.

Архитектурное несоответствие

Официальный сервер Bitwarden представляет собой тяжеловесный стек на C# / .NET / MSSQL Express, который не работает с PostgreSQL или MariaDB. Сторонники self-hosting'а ещё много лет назад обошли это ограничение с помощью vaultwarden (написанного dani-garcia на Rust), набравшего примерно втрое больше звёзд на GitHub, чем официальный сервер. Реакцией Bitwarden на этот факт стал найм главного разработчика Vaultwarden и выпуск "Bitwarden lite" - всё ещё на .NET и всё ещё требующего примерно в 3 раза больше RAM, чем Vaultwarden, - вместо перехода на реализацию от сообщества. Синдром NIH ("not invented here"), по мнению Marius'а, победил здравый инженерный подход.

Мелкие проблемы клиентов

Миграция сломана в обоих направлениях. Импорт из конкурирующих менеджеров сбоит на популярных форматах, причём как минимум один хорошо задокументированный баг игнорируется, несмотря на упоминание на маркетинговой странице. Для перемещения записей между хранилищем организации и личным хранилищем спустя десять лет так и не появилось UI: официальный обходной путь - экспорт в незашифрованный JSON, ручное редактирование и повторный импорт. При таком экспорте теряются вложения, корзина, история паролей и временные метки.

Обновления клиентов приносят ломающие изменения протокола без всякого предупреждения. F-Droid ночью автоматически обновил клиент для Android, пока Marius был в поездке, заблокировав ему доступ к хранилищу до тех пор, пока он не смог добраться до своего self-hosted бэкенда. Приложение для Android в 2024 году пережило полное переписывание с .NET MAUI на Kotlin, но регрессии продолжают появляться в квартальных релизах.

UX остаётся постоянным источником раздражения: ощутимая задержка при каждой разблокировке из-за попыток клиента связаться с бэкендом даже в офлайн-режиме, отсутствие возможности отключить синхронизацию при разблокировке, элементы списка в хранилище открывают запись вместо автозаполнения формы (за автозаполнение отвечает отдельная маленькая кнопка Fill), проблемы с Wayland Flatpak, сломанный биометрический вход на iOS, регулярные жалобы на Hacker News на "неработающие подсказки для входа". Запросы на доработку от 2021 года (базовая история правок) до сих пор не тронуты. Реселлеры MSP публично называют это "ледниковыми темпами разработки".

CLI - отдельная проблема: команда bw list выводит все учётные данные целиком без явного флага подтверждения, а сам CLI написан на Node.js / TypeScript со всеми вытекающими рисками из-за дерева зависимостей. Именно это и сделало возможным инцидент в цепочке поставок 2026 года.

Пять инцидентов безопасности как закономерность

Аргументация Marius'а опирается не столько на отдельный инцидент, сколько на общую картину:

• 2023 - уязвимость KDF. Владимир Палант (Wladimir Palant) показал, что заявленные Bitwarden 200 001 итераций PBKDF2 на практике составляли около 100 000 для ключа шифрования: серверные итерации применялись только к хешу для входа. Количество итераций на клиенте по умолчанию также составляло 100 000, что ниже рекомендаций OWASP, хотя поднять планку обещали ещё в 2020 году. В итоге Bitwarden перешёл на 600 000 итераций и добавил Argon2 - но только для новых аккаунтов; существующим пользователям пришлось обновлять настройки KDF вручную. Ту же ошибку ранее совершил LastPass.
• 2023 - обход Windows Hello. "Bitwarden Heist" от RedTeam Pentesting (CVE-2023-27706): непривилегированные процессы могли извлечь ключ хранилища из DPAPI без запроса Windows Hello или мастер-пароля. Исправление вышло лишь спустя месяцы после раскрытия уязвимости в версии 2023.4.0.
• 2023 - автозаполнение cross-origin. CVE-2023-27974: браузерное расширение автоматически подставляло учётные данные в междоменные iframe'ы, если совпадал базовый домен. Bitwarden ответил, что iframe'ы "должны обрабатываться именно так из соображений совместимости".
• 2025 - DOM-кликоджеккинг. Раскрытие Марека Тота (Marek Tóth) в августе 2025 года: расширение можно было заставить автоматически заполнить данные банковских карт и персональную информацию на вредоносной странице по одиночному клику. Уязвимость отправлена в апреле 2025 года, получила средний уровень критичности и была закрыта в 2025.8.2 в день истечения эмбарго.
• 2026 - атака на цепочку поставок Shai-Hulud / Checkmarx. Пакет @bitwarden/cli 2026.4.0 был опубликован с полезной нагрузкой bw1.js через скомпрометированный GitHub Action в их пайплайне CI/CD. Нагрузка скачивала среду исполнения Bun, расшифровывала червя Shai-Hulud и собирала токены GitHub/npm, ключи SSH, историю командной строки, учётные данные AWS/GCP/Azure, секреты GitHub Actions и конфигурации MCP. Украденные данные отправлялись наружу через автоматическое создание публичного репозитория на GitHub жертвы. Вредоносная версия была доступна около 19 часов; её успели скачать 334 разработчика. В официальном заявлении Bitwarden подчеркнула, что данные хранилищ конечных пользователей не пострадали - факт верный, но не отменяющий сути проблемы. См. supply-chain-security о закономерностях таких атак.

Закономерность, которую выделяет Marius, - это реактивная безопасность вместо проактивной, ответы в духе "так и задумано" на неудобные находки и структурная хрупкость распространения CLI для безопасности через npm, когда большая часть экосистемы перешла на единые статические бинарники.

Путь вперёд: разделяй и властвуй

В качестве альтернативы Marius предлагает не другое единое хранилище, а осознанное разделение секретов на пять групп, где инструмент подобран под конкретную задачу. См. credential-compartmentalization для подробного разбора концепции.

• Группа A - клиентская и профессиональная работа. Облачный менеджер паролей с возможностью совместного доступа, SSO и журналами аудита. Компромисс в пользу проприетарного решения принят, поскольку область применения строго ограничена.
• Группа B - аккаунты с персональными данными (PII) (банки, интернет-магазины). Второй облачный менеджер паролей от другого вендора, с другим мастер-паролем и другой процедурой восстановления - чтобы компрометация группы A не привела к компрометации группы B. Мобильный клиент не должен требовать Google Play Services (автор использует GrapheneOS).
• Группа C - аккаунты без персональных данных (форумы, временные сервисы). KeePassXC / KeePassChi / KeePassDX с файлом .kdbx, синхронизируемым через Syncthing. Сам файл зашифрован, поэтому компрометация Syncthing не ведёт к прямой утечке секретов.
• Группа D - инфраструктура (серверы, SSH, CI). Учётные данные личной инфраструктуры хранятся как группа C; секреты для автоматизации - в HashiCorp Vault для использования политик, аутентификации по токенам, короткоживущих учётных данных и журналов аудита. Присматривается к Infisical.
• Группа E - разовые секреты для CLI (API-ключи, токены). Утилита pass - отдельный зашифрованный с помощью GPG файл на каждый секрет в Git-репозитории на собственной инфраструктуре с ручной синхронизацией.

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

См. также

• bitwarden - страница сущности, основание, владельцы, разделение продуктов
• vaultwarden - Bitwarden-совместимый сервер от сообщества на Rust
• credential-compartmentalization - шаблон разделения секретов от Marius'а как концепция
• supply-chain-security - инцидент с Shai-Hulud / Bitwarden CLI в контексте
• living-off-the-land - смежный паттерн атак: легитимные инструменты в качестве вредоносного ПО
• hold-on-to-your-hardware - более ранняя публикация того же автора
• marius-blog - блог автора как отслеживаемый источник