Менеджеры паролей

Что такое Менеджеры паролей

Менеджер паролей — программа, которая хранит логины и пароли в зашифрованном хранилище, генерирует новые и подставляет их в формы входа. Всё хранилище шифруется одним мастер-паролем — единственным, который нужно помнить.

Задача, которую он решает, — не «лень запоминать». Человек физически не способен помнить полсотни длинных случайных паролей, поэтому без менеджера неизбежно наступает одно из двух: пароли простые либо одинаковые. Второе опаснее. Утекает база какого-нибудь форума — и атакующий подставляет ту же пару логин-пароль в почту, банк и панель хостинга. Это credential stuffing, самая массовая атака в интернете, и она работает исключительно на переиспользовании паролей.

Недооценённый бонус: менеджер не подставит пароль на фишинговом сайте. Он сверяет домен, и на sberbonk.ru поле останется пустым. Человек не заметит подмены одной буквы, программа — заметит. Фактически автозаполнение работает как защита от социальной инженерии.

Как устроено

Архитектура называется zero-knowledge: сервер хранит только зашифрованный блоб и не может его прочитать. Мастер-пароль никогда не покидает устройство и на сервер не отправляется.

Мастер-пароль
    ↓ KDF (Argon2id / PBKDF2, сотни тысяч итераций)
Ключ шифрования  ─── остаётся на устройстве
    ↓
AES-256 ──→ зашифрованное хранилище ──→ синхронизация на сервер

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

Обратная сторона zero-knowledge: забытый мастер-пароль означает потерю всего. Восстановления нет — в этом весь смысл. Ключ восстановления хранят офлайн, на бумаге.

Варианты

Self-hosted против облака — обычный размен. Свой сервер даёт контроль над данными и попадает под требования, если пароли считаются конфиденциальной информацией компании. Он же означает, что бэкапы, TLS и доступность — теперь ваша забота: упавший сервер с менеджером паролей блокирует работу всей команды. Держите его в Docker с автоматическим бэкапом тома и офлайн-копией на случай отказа.

Пароли и секреты — разные задачи

Частая архитектурная ошибка — складывать в менеджер паролей секреты инфраструктуры. Пароль от БД, API-ключ для CI/CD, приватный ключ — это секреты, и им нужно другое: программный доступ, автоматическая ротация, выдача на время, аудит обращений.

Для root-доступа к серверам и админских учёток БД существует отдельный класс — PAM, см. IAM.

Практика

• 2FA на сам менеджер — обязательно. Это хранилище всего.
• TOTP-коды в том же хранилище — спорно: два фактора в одной корзине сводят 2FA к одному. Для критичных аккаунтов держите их отдельно.
• Passkey менеджеры уже поддерживают — постепенно они заменяют пароли, а не дополняют.
• Общие пароли в команде — только через организацию с коллекциями, а не пересылкой в мессенджере. Уход сотрудника = отзыв доступа к коллекции, а не смена паролей вручную.
• Проверяйте утечки. Встроенные отчёты Bitwarden и Have I Been Pwned показывают скомпрометированные и повторяющиеся записи.

Связанные термины

• Аутентификация — процесс, в котором участвует пароль
• Двухфакторная аутентификация — второй барьер поверх пароля
• Атаки и социальная инженерия — брутфорс, фишинг и credential stuffing
• Bitwarden — популярный self-hosted вариант
• HashiCorp Vault — для секретов приложений, а не паролей людей