# Pix Vault — безопасный план менеджера паролей

## Базовый принцип

Не реализовывать свой криптографический протокол и не смешивать вход в Pix Account с разблокировкой хранилища. Pix Account идентифицирует пользователя и может запускать Vault; только отдельный мастер-секрет/ключ разблокирует локально или клиентом зашифрованное хранилище. SSO token, Firebase token и восстановление аккаунта не должны расшифровывать vault.

Bitwarden официального self-hosted семейства — один кандидат для проверки, не утверждённый выбор. До ADR проверить актуальные редакции/лицензии и условия самохостинга, функции синхронизации/организаций/SSO, возможность использовать официальные клиенты и расширения, стоимость, security advisories, миграцию и ограничения ребрендинга. Сравнить с поддерживаемыми альтернативами по тому же списку; не форкать мобильные клиенты для косметики в MVP.

## Сравнение вариантов и решение для первого пилота

| Основа | Что даёт | Ограничения для Pix | Рекомендуемое применение |
|---|---|---|---|
| **Bitwarden Lite (официальный)** | Официальный single-container self-host путь, который Bitwarden позиционирует для личного использования, homelab и лёгкого sharing; web/mobile/extensions и существующий encrypted sync protocol | Это отдельный Bitwarden продукт, не Pix Vault; возможности зависят от тарифа и конкретной версии. Часть функций требует подписки/лицензии; production-услуга с переработанным AGPL-сервером требует отдельной юридической оценки лицензий/товарных знаков | Первый закрытый технический пилот официальных клиентов с собственным сервером под отдельным origin, без форка/ребрендинга |
| **Официальный Bitwarden self-host (standard/Helm)** | Наиболее прямой путь к поддерживаемому backend и официальным приложениям; документированные deployment и backup-процедуры | Standard deployment использует Docker и MSSQL; заметно тяжелее нынешнего небольшого VPS. Организационные, enterprise, SSO и некоторые коммерческие модули лицензируются отдельно | Повторная оценка после отдельного хранилища, резервного сервера и лицензии/ресурсов |
| **Vaultwarden** | Лёгкая community-реализация совместимого API на Rust, AGPL-3.0; поддерживает официальные Bitwarden-клиенты, неофициальный проект | Сам проект подчёркивает unofficial статус; Bitwarden не гарантирует полную совместимость и ограничивает поддержку клиентов. Возможности и совместимость могут расходиться с каждым клиентским релизом. Нельзя обещать parity по passkeys, организациям или SSO | Только изолированный тестовый стенд, если официальный лёгкий backend не проходит ресурсные ограничения; никакого общего пользовательского пилота до ежедневной проверки совместимости |
| **KeePassXC + KeePassXC-Browser** | Зрелое локальное KDBX-хранилище; GPL-2.0/GPL-3.0. Браузерное заполнение проходит через desktop app/native messaging; синхронизацию файла можно организовать независимо от поставщика | Нет Pix-сервера и штатной облачной синхронизации; на телефонах нужен отдельный KeePass-compatible клиент; конфликтующий одновременный sync-файл усложняет UX. Не обеспечивает единый серверный account | Хороший локальный контрольный вариант приоритетно для desktop, но не база Pix multi-device service |

**Рекомендация:** начать с закрытого одно-пользовательского пилота Bitwarden Lite с неизменёнными официальными клиентами. Это позволяет проверить реальный UX и модель синхронизации без собственного кода для шифрования. Пользователь входит в отдельный Vault account и задаёт отдельный master password; Pix Account на первом этапе только показывает ссылку/запускает клиент. Это ещё не Pix-ребрендинг и не доступный всем сервис.

Перед запуском подтвердить, что выбранная сборка Bitwarden Lite и условия лицензии подходят для предполагаемого использования. В лицензировании проверять не только репозиторий целиком, но и точные модули, исходный образ и способ его предоставления пользователям: Bitwarden указывает GPL/AGPL для основных компонентов, а часть модулей и функций — под Bitwarden License с production-ограничениями; товарные знаки регулируются отдельно. AGPL-код, коммерческие дополнения, брендинг и обслуживание стороннего сервиса требуют отдельного review. Не выдавать Vaultwarden за официальный Bitwarden и не обещать совместимость, гарантированную только самим проектом.

Источники: [Bitwarden self-host](https://bitwarden.com/help/self-host-bitwarden/), [self-host FAQs](https://bitwarden.com/help/hosting-faqs/), [license FAQ](https://github.com/bitwarden/server/blob/main/LICENSE_FAQ.md), [trademark guidelines](https://github.com/bitwarden/server/blob/main/TRADEMARK_GUIDELINES.md), [Vaultwarden](https://github.com/dani-garcia/vaultwarden), [KeePassXC user guide](https://keepassxc.org/docs/KeePassXC_UserGuide), [KeePassXC licenses](https://github.com/keepassxreboot/keepassxc).

## Pix Account и клиентская интеграция

**Пилотная схема:** Pix Hub содержит ссылку «Pix Vault» на отдельный hostname (не путь вида `/vault`: стандартный Bitwarden self-hosted не поддерживает deployment в подкаталог). Официальные Bitwarden приложения/расширения настраиваются на этот серверный URL и обрабатывают шифрование, unlock, encrypted sync и autofill. Не встраивать web vault внутрь Messenger/Study iframe, не принимать экспортированное содержимое vault в Pix Account и не передавать токен Pix OIDC в Bitwarden API. На текущем 1-vCPU/около-3-GiB сервере не разворачивать standard MSSQL deployment без повторного capacity-плана; проверить Lite в изоляции и измерить память/диск под фактической нагрузкой.

В пилоте Pix Account остаётся каталогом приложений: вход, email reset и удаление Pix Account независимы от Vault. Даже если позднее добавить OIDC-вход, он только аутентифицирует пользователя и не должен доставать или выводить master key. Связь Pix ID ↔ отдельный Vault account должна быть добровольной, явно подтверждаемой и отзываемой, хранить только псевдоним/внешний subject ID. Не синхронизировать пароль, recovery secret, приватный ключ устройства или decrypted data между приложениями. Просматривать/управлять секретами пользователь должен в штатном клиенте провайдера.

Для Firefox и Safari использовать официальное расширение/поддерживаемый клиент и встроенное сопоставление URI/origin: разрешить только точное HTTPS origin, не подставлять по похожему домену, выключить автозаполнение до явного действия пользователя. Для Android тестировать штатный Autofill Framework через официальное приложение; не реализовывать Pix Accessibility Service/клавиатуру, которая читает поля других приложений. Autofill — отдельное разрешение пользователя; вести понятный экран отключения/отзыва. Источник passkey-рекомендаций: [Bitwarden auto-fill](https://bitwarden.com/help/auto-fill-browser/) и [официальный перечень возможностей self-hosted](https://bitwarden.com/help/self-host-bitwarden/).

Passkeys не включать как критерий запуска. Официальная документация Bitwarden сообщает о хранении passkeys на self-hosted серверах, но отдельно описывает passkey как 2FA-вход, совместимость которого зависит от приложения/браузера и конфигурации self-host. Passkeys внутри пользовательского сейфа и passkeys для входа в Pix Account — разные потоки. Сначала проверить create → save → sync → fill/login → revoke/delete на точных версиях официальных clients и server. Не называть Pix Account passkey-support завершённой фичей на основании одной лишь поддержки провайдером.

## Восстановление, блокировка и потеря устройства

- Master password / local unlock принадлежит Vault и не сбрасывается reset’ом Pix Account.
- До сохранения любых секретов клиент должен объяснить, что потеря master password и предусмотренного recovery-секрета может сделать данные невосстановимыми; серверный backup хранит ciphertext и сам по себе не позволяет открыть его.
- Account recovery, provider-side recovery, emergency access, two-step login recovery и восстановление master key — отдельные операции. Никакая из них не должна тихо менять encryption key.
- Включить export/restore walkthrough с тестовым сейфом до настоящих записей. Проверить export после отзыва устройства и удаление учётной записи вместе с описанным backup-retention.
- Passkey/platform sync (например, системный keychain) может копировать credential за пределы Pix; заранее раскрыть пользователю, куда синхронизируется passkey и кто контролирует копии.

## Данные и модель ключей

Устройство шифрует vault до загрузки, используя upstream-reviewed KDF и envelope encryption. Сервер хранит только зашифрованные blobs плюс необходимую синхронизационную метаинформацию. Точные алгоритмы, форматы и параметры берутся из выбранного проверенного продукта и документируются в ADR; здесь не задаётся новый протокол.

Мастер-пароль не отправляется серверу в открытом виде. Recovery key либо хранится у пользователя отдельно/offline, либо включается в явную модель доверенного emergency contact; не класть его в Pix Account, Mail, Drive или те же backup-ключи. Если recovery secret потерян, честно сообщить, что сохранённые записи могут оказаться невосстановимыми. Сброс Pix Account password не сбрасывает ключ Vault.

## Модель угроз и приватности

### Защищаемые активы

- Пароли, TOTP seeds, passkeys/private keys, secure notes, attachments и история изменений.
- Ключи шифрования, recovery material, локальные unlock tokens, сессии и экспортированные plaintext-файлы.
- Связь между Pix ID, аккаунтом Vault и устройствами; привычки входа/autofill и факт существования конкретной учётной записи.

### Противники и допущения

Проектируем защиту от кражи серверной базы или backup, сетевого наблюдателя, другого обычного пользователя сервиса, утёкшей сессии/похищенного телефона, случайного просмотра экрана/clipboard, вредоносной страницы, lookalike origin и операционной ошибки администратора. Облачный/серверный оператор считается способным читать серверную БД, логи и метаданные, менять доступность, блокировать/откатывать sync и наблюдать IP/время соединения. Цель шифрования на клиенте — не дать одному только чтению backend ciphertext раскрыть содержимое сейфа.

Не обещаем защиту от malware/keylogger с правами пользователя, компрометации ОС или браузера, злонамеренного/подменённого клиента или обновления, физически разблокированного устройства, слабого мастер-пароля после утечки ciphertext, принуждения пользователя или утечки plaintext самим получателем. Клиент с правом расшифровки может раскрыть данные; E2EE не устраняет этот риск. Оператор всё равно видит неизбежные сервисные метаданные: IP и время запросов, объём/число sync-пакетов, версии клиентов, факт входа и идентификаторы устройств. Если конкретный upstream передаёт дополнительные поля (например, email, item count, attachment metadata), их нужно перечислить после проверки схемы продукта — считать метаданные скрытыми нельзя.

### Требуемые свойства и остаточный риск

| Событие | Требование | Остаточный риск |
|---|---|---|
| Чтение базы/backup только на сервере | База содержит ciphertext; ключ расшифрования и recovery secret не хранятся доступными backend | Трафик/частота/размер, сетевые идентификаторы и другие protocol metadata могут остаться видимыми; offline guessing слабого master password зависит от точной схемы upstream/KDF |
| Сброс или takeover Pix Account | Не выдаёт ключ и не восстанавливает содержимое Vault; отдельное подтверждение добавления/удаления интеграции | Захват отдельного Vault account или уже разблокированного клиента остаётся самостоятельной угрозой |
| Кража заблокированного устройства | Локальный cache зашифрован upstream-механизмом, блокировка требует повторного unlock по установленной политике | Компрометация ОС, украденная активная сессия или слабая локальная биометрическая граница могут обойти ожидания пользователя |
| Потеря устройства / отзыв сессии | Можно отозвать сессию и видеть устройства; отзыв запрещает дальнейший sync | Нельзя удалённо стереть plaintext, ciphertext/export или ключ, уже скопированный на офлайн-устройство |
| Поддельный сайт/autofill | Совпадение только точного HTTPS origin/app identity, явное действие пользователя, защита от lookalike | Подмена DNS/CA, вредоносное расширение или корректный, но скомпрометированный сайт всё ещё риск |
| Ошибка backup/удаления | Документированная retention policy и регулярно проверяемое восстановление/удаление | Копии на устройстве пользователя и backup до конца объявленного retention не исчезают мгновенно |

Требуемые меры до пилота: закреплённый и проверяемый upstream release; проверка независимым security review; TLS на отдельном origin; закрытый/минимальный admin surface и регистрация только по приглашению; редактирование секретов и auth headers в логах; короткая политика хранения connection logs; запрет аналитики содержимого; отдельный ciphertext backup с ограниченным доступом и тестом restore; мониторинг обновлений и уязвимостей. Не добавлять свои crypto/KDF форматы, recovery escrow или общие backend-ключи «для удобства».

### Passkeys и разблокировка — разные ключи и границы

Passkey платформы может быть удобным локальным способом подтвердить присутствие пользователя, но сам факт passkey-входа не доказывает, что сервер не получил ключ vault: это зависит от протокола и конкретного клиента. До выбора upstream документировать, как именно локальный unlock secret защищён и что passkey unlock/recovery способен сделать. Не называть биометрию самостоятельным recovery-планом: она может зависеть от platform key store и исчезнуть при сбросе устройства. Pix Account passkey — credential входа в каталог приложений; passkey, лежащий как запись в менеджере, — содержимое самого сейфа. Они не должны автоматически разблокировать друг друга.

### Recovery, экспорт и удаление: MVP-контракт

- **Setup:** пользователь создаёт самостоятельный Vault account или локальный сейф и видит предупреждение о необратимой потере при утрате master/recovery secret. Pix Account может быть необязательной ссылкой-ярлыком, не источником ключа.
- **Unlock:** локальная разблокировка; auto-lock при фоне/таймауте настраивается. Биометрия только включается поверх поддерживаемого secure storage и с понятным запасным способом; не обходить системные политики.
- **Recovery:** в первом MVP только проверенный upstream-путь либо offline recovery key с обязательным тестом на втором чистом устройстве. Email reset/SSO и support-оператор не расшифровывают данные. Если продукт не имеет безопасного recovery, явно показать «не восстановить» и не имитировать восстановление.
- **Export:** явный повторный unlock, предупреждение о plaintext, минимальный временный файл, очистка буфера/временных данных где поддерживается и инструкция удалить экспорт вручную. Проверить формат на совместимый импорт; не загружать экспорт в Pix Mail/Drive по умолчанию.
- **Device/session:** список только необходимой идентифицирующей информации и времени, revoke с подтверждением. После revoke объяснить, что он не стирает локальные копии и не гарантирует отзыв уже скачанного ciphertext.
- **Delete:** пользователь отдельно закрывает аккаунт у выбранного провайдера и получает понятную дату purge из primary store и backup retention. Удаление Pix Account/unlink само по себе не объявляется удалением Vault, offline cache или уже экспортированных файлов.

### MVP: что входит и что исключено

Входит: тестовый single-user encrypted vault на неизменённом проверяемом продукте; генерация сильных случайных паролей; базовые записи login/secure note; ручная блокировка/таймаут; masked values; явное копирование с очисткой clipboard best effort; обзор устройств/revoke; экспорт и recovery walkthrough; проверка синхронизации на Firefox, Safari и Android штатными поддерживаемыми клиентами; минимальный приватный service status.

Исключено до аудита: самописная криптография или замена протокола upstream; совместные сейфы/emergency contact; доступ поддержки к plaintext; recovery escrow на Pix Account; пароли/passkeys в Pix Hub/SSO; autofill собственного расширения, клавиатуры или Android Accessibility Service; автоматическое заполнение без явного жеста; breach API, который получает пароль/полный хеш; вложения; импорт боевых баз; реклама/поведенческая аналитика; публичная self-service регистрация; обещания «нулевых метаданных» или абсолютной защиты.

### Тесты угроз для закрытого пилота

1. Сделать ciphertext-only снимок тестовой backend DB и backup; проверить, что известные тестовые пароли и secure notes не находятся поиском, а вход в Pix Account не даёт их расшифровать.
2. Сменить/сбросить пароль Pix Account, отозвать Vault-сессию и удалить связь: ни один шаг не восстанавливает ключ, не экспортирует содержимое и не объявляет удаление, которое не было подтверждено фактической retention policy.
3. Установить второй чистый клиент, восстановить только предусмотренным пользователем способом и проверить negative case с неверным/утерянным recovery material.
4. Проверить logout/lock, background timeout, reboot и revoke потерянного устройства; зафиксировать, какие local caches и уже загруженные данные сохраняются.
5. Проверить экспорт/импорт, clipboard и логи на тестовом секрете; секрет не появляется в URL, browser console, reverse-proxy/app logs, crash reporting или аналитике.
6. Если добавляется autofill позднее: отрицательные тесты HTTP, поддоменов-подделок, похожих символов, cross-origin iframe, нескольких логинов и слабого match; по умолчанию секрет не подставляется.

Эти пункты уточняют, что именно надо проверить в выбранном продукте; они не подтверждают, что текущая инфраструктура или upstream уже обеспечивает эти свойства.

## Потоки и границы

```text
Pix Account OIDC → профиль/права входа → Vault client
Vault master secret → локальная разблокировка → decrypt/encrypt on-device
Vault client ── encrypted sync payload ──> vault backend
Browser extension / Android autofill → разрешённые origin/app IDs, локальная разблокировка
```

Каждое устройство отдельно авторизуется, показывает имя/последний доступ и может быть отозвано. Отзыв сессии предотвращает будущую синхронизацию, но сам по себе не удаляет уже загруженный шифротекст или копии на доверенном устройстве. Общие сейфы, sharing, autofill в чужой iframe и desktop clipboard sync — не MVP.

Threats: keylogger/malware на клиенте, XSS в web-клиенте, clipboard exposure, слабый master password, backup/recovery compromise, компрометация сервера/админ-панели, supply-chain update. E2EE защищает от части серверных утечек, но не от вредоносного разблокированного устройства или подменённого клиента.

## Функции и этапы

**Прототип:** на тестовых записях импорт/экспорт выбранной основы, локальная блокировка, генератор случайных паролей, копирование с очисткой буфера при поддержке, auto-lock timeout, masked values и отсутствие секретов в логах.

**Пилот:** синхронизация через проверенный backend, device/session view, отозвать устройство, master-secret setup/recovery education, encrypted backup/restore на чистом втором устройстве, plaintext-free diagnostics. Каждый security-sensitive action просит локальную повторную разблокировку.

**После аудита:** Android Autofill service, браузерное расширение с strict origin matching, passkeys, breach/reuse проверки локально с privacy-preserving feed. Внешний breach check не отправляет пароль или его полный хеш без отдельного протокола и согласия.

## Критерии пилота

Запустить только на тестовом аккаунте и тестовых логинах. Переход к боевым данным разрешён лишь после независимого security review и выполнения всех пунктов:

1. Одно и то же тестовое хранилище создаётся, блокируется, синхронизируется, редактируется и удаляется на Firefox + Safari + Android через выбранные штатные клиенты; параллельное редактирование и сетевой retry не теряют изменений.
2. Смена/сброс Pix Account password не расшифровывает vault; удаление Pix Account или отключение интеграции не заявляется как гарантированное удаление provider-side данных и локальных копий. Пользователь может отдельно удалить vault и отозвать устройства.
3. Новый Android/browser device получает только ciphertext до локального разрешённого unlock; восстановление проверено на чистом устройстве, а потеря master/recovery secret отображается явно.
4. Autofill работает только после явного жеста и на точном origin; тесты на lookalike domain, HTTP, iframe, пустой match и несколько login entries не раскрывают секреты и не подставляют автоматически.
5. Настоящие secret values отсутствуют в серверных/app logs, URL, crash telemetry и аналитике; публичная admin-страница, signup, приглашения и diagnostics отключены или защищены; HTTPS и origin корректны, backup регулярно проверяется через restore.
6. Замерены peak RSS, storage, restore time и sync latency на целевом VPS; при устойчивом дефиците ресурсов пилот остаётся локальным и не масштабируется добавлением других сервисов на тот же узел.
7. Проверены точные версии серверного образа, web vault и клиентов, источник/подписи/релизные advisories, официальные права использования и возможность отката сервера без потери совместимости данных.

## Критерии допуска к реальным секретам

- Документированный формат/алгоритмы upstream и peer-reviewed криптографическая схема; проверены официальные клиенты и подписи релизов.
- Restore на чистом устройстве работает только с предусмотренными пользователем credentials/recovery; Account reset сам по себе не открывает записи.
- Проверены отзыв утраченного устройства, logout/lock, export и полное удаление аккаунта согласно backup-retention.
- В браузерной версии CSP без inline-скриптов, зависимости закреплены и сканируются, XSS-тесты блокируют чтение decrypted state вне vault UI; секреты/токены не попадают в telemetry или console/server logs.
- До загрузки настоящих паролей завершён внешний security review. Не использовать боевые учётные данные во время раннего UX-прототипа.