Безопасность и модель угроз

1. Модель угроз: что сервер видит

Zero-knowledge не значит «сервер вообще ничего не знает». Мы прямо перечисляем, что сервер технически способен увидеть, даже при полностью честной работе кода:

• Email — используется для входа и связи, хранится в открытом виде.
• Название хранилища — не шифруется в текущей версии: это осознанный компромисс в пользу простоты. Содержимое записей внутри хранилища зашифровано полностью, но само название сейфа сервер видит.
• Факт существования и структура шаринга — кто с кем какое хранилище расшарил, сколько в нём записей, когда они создавались/менялись (метаданные, не содержимое).
• IP-адрес и User-Agent — хранятся только как необратимый хеш с секретной солью, для rate-limit и защиты сессии; не как сырые значения.
• Гостевые ссылки — сервер видит факт создания, срок действия, число просмотров — но не расшифрованное содержимое записи и не ключ доступа (он живёт только в URL-фрагменте у получателя, никогда не отправляется на сервер).

Если сервер (или база данных целиком) будет скомпрометирован, злоумышленник получит эти метаданные — но не пароли, не мастер-ключ, не приватные ключи участников, не содержимое ни одной записи. Мы считаем важным проговорить это прямо, а не оставлять как подразумеваемую гарантию.

2. Что сервер физически не может увидеть

• Мастер-пароль — никогда не покидает браузер ни в открытом, ни в обратимом виде. На сервер уходит только производный authHash, из которого восстановить пароль нельзя.
• Ключи расшифровки — приватный ключ пользователя (X25519) хранится на сервере только в виде, зашифрованном мастер-ключом; ключ сейфа (vault key) передаётся между участниками только запечатанным под их публичные ключи.
• Содержимое записей — логины, пароли, заметки, URL — зашифрованы AES-256-GCM ключом сейфа ещё до отправки на сервер. Сервер хранит только шифротекст.
• Содержимое гостевых ссылок — перешифровано отдельным одноразовым ключом, который никогда не передаётся серверу — только получателю, в URL-фрагменте (fragment не отправляется в HTTP-заголовках).

3. Криптографические примитивы

Вся криптография выполняется на клиенте через libsodium-WASM и встроенный Web Crypto API браузера — общедоступные, независимо аудированные реализации, а не собственный код шифрования.

4. Что происходит при разных сценариях компрометации

• Утечка базы данных целиком. Злоумышленник получает email, названия сейфов, метаданные шаринга и активности, зашифрованные блобы записей. Не получает: пароли, ключи, содержимое записей.
• Компрометация сервера (RCE). Теоретически позволяет читать данные будущих запросов «на лету» до шифрования на клиенте — этот риск не устраняется zero-knowledge архитектурой полностью, только снижается: он требует активной, направленной атаки на инфраструктуру, а не просто кражи базы.
• Кража сессионного токена. Токен передаётся только в заголовке Authorization: Bearer (не в cookie — CSRF-поверхность закрыта по дизайну), живёт ограниченное время, привязан к User-Agent. Даёт доступ к хранилищам, но не к мастер-паролю.
• Физический доступ к разблокированному устройству. Смягчается Panic Mode (экстренное завершение сессии) и опциональным PIN на конкретное хранилище — второй слой поверх обычной сессии.

5. Приглашение к независимому аудиту

Мы не проводили формальный внешний аудит безопасности на момент публикации этой страницы. Мы приглашаем исследователей безопасности изучить архитектуру и код и сообщить о находках по адресу security@safekom.ru. Мы обязуемся:

• Подтвердить получение отчёта в течение 3 рабочих дней.
• Не предпринимать юридических действий против исследователей, действующих добросовестно и не нарушающих данные пользователей.
• Публично поблагодарить за существенные находки (по согласованию с исследователем).

Формальной bug bounty-программы с денежным вознаграждением пока нет — это responsible disclosure канал. См. также Политику конфиденциальности и Условия использования.