Почему ваш password manager может быть не безопаснее блокнота

Большинство password manager’ов заявляют, что ваши данные защищены, однако в реальности архитектура многих из них допускает сценарии, при которых сервер либо канал связи потенциально может быть слабой стороной.

Где ломается модель “безопасного” password manager’а

Типичная схема выглядит так:

На первый взгляд — всё ок, но есть вопрос: кто и где выполняет шифрование — и как управляются ключи ?

Вот здесь и начинаются основные риски.

Основные уязвимости

1. Передача данных без должной защиты

В некоторых реализациях можно встретить ситуации, когда:

- часть данных передаётся до шифрования

- используются небезопасные или неправильно настроенные протоколы

- отсутствует строгий контроль TLS (например, отсутствие pinning)

Это открывает возможности для:

- перехвата трафика (MITM)

- анализа данных в процессе передачи

Даже кратковременная передача незашифрованной информации может привести к компрометации.

2. Сервер участвует в криптографии

Если сервер:

- участвует в генерации ключей

- или получает производные от них

→ он становится потенциальной точкой компрометации

Даже если “формально” данные зашифрованы.

3. Слабая или неправильная KDF

Многие системы:

- используют устаревшие алгоритмы

- или недостаточные параметры

Это делает возможным:

- brute-force

- оффлайн-атаки при утечке базы

4. Утечки через метаданные

Даже если данные зашифрованы:

- названия сайтов

- структура записей

- частота обращений

могут утекать и давать полезную информацию атакующему.

5. Избыточные разрешения приложений

Отдельный класс рисков связан не с криптографией, а с самим окружением.

В некоторых случаях приложения могут запрашивать избыточные разрешения, не всегда очевидно связанные с их основной функцией.

Это может быть связано с:

- встроенными механизмами автозаполнения

- дополнительными функциями

- или особенностями платформы

Однако такие разрешения увеличивают поверхность атаки и требуют дополнительного доверия к приложению.

Это создаёт дополнительные векторы риска:

- компрометация через уязвимости приложения

- сбор лишних данных

- расширенная поверхность атаки

Чем больше прав у приложения — тем выше потенциальный ущерб при его взломе.

6. Доверие к backend’у

Самый важный момент:

Во многих реализациях предполагается, что сервер:

- “честный”

- не подменяет код

- не вмешивается в процесс

На практике это допущение часто не проверяется. Как должна выглядеть более безопасная архитектура?

Если упростить — система должна быть построена так, чтобы сервер в принципе не мог прочитать данные, даже если захочет, а протокол передачи данных в случае перехвата был шифрованным.

Это достигается за счёт нескольких принципов.

1. Шифрование на клиенте

Все данные должны шифроваться до отправки. Сервер получает только:

- ciphertext

- без возможности расшифровки

2. Надёжная KDF - ключ должен выводиться из мастер-пароля с использованием:

- Argon2id

- с достаточными параметрами памяти и времени

Это делает оффлайн-атаки крайне дорогими.

3. Современная симметричная криптография для хранения данных, например AES-256-GCM или аналогичные схемы с аутентификацией

Это защищает не только содержимое, но и целостность (технология block-chain)

4. Zero-knowledge backend

Сервер:

- не знает ключей

- не участвует в расшифровке

- не может интерпретировать данные

Он выполняет только роль:

- хранения

- синхронизации

5. Локальное хранение

Хорошая практика — хранить данные локально (например, в IndexedDB):

- в зашифрованном виде

- с последующей синхронизацией

Это даёт:

- работу оффлайн

- снижение зависимости от сервера Что происходит при компрометации базыЕсли всё сделано правильно:

- атакующий получает только зашифрованные данные

- без ключа они бесполезны

- единственный вариант — brute-force мастер-пароля

При корректной KDF это практически неосуществимо.

Почему это важно

Многие пользователи думают:

“Если сервис популярный — значит безопасный”

Но безопасность — это не популярность.

Это архитектура.

И главное свойство хорошей системы:

она остаётся безопасной даже при недоверии к серверу

Пример практической реализации

В качестве примера можно привести простой кроссплатформенный проект — Lockly, реализующий описанный подход и недавно вышедший в публичный доступ.

Он построен на тех же принципах:

- клиентское шифрование

- использование Argon2id для вывода ключа

- применение AES-GCM для хранения данных

- zero-knowledge backend

- синхронизация без доступа сервера к данным

Итог

Опыт использования различных password manager’ов со временем показывает одну и ту же проблему:

безопасность часто строится на доверии к бренду или массовым предпочтениям, а не на анализе архитектуры

Если система допускает возможность доступа к данным — рано или поздно этот сценарий может реализоваться.

Если же архитектура изначально исключает такую возможность, даже при компрометации сервера данные остаются защищёнными.

Именно этот принцип кажется наиболее важным при выборе инструментов для хранения чувствительной информации.