Менеджер паролей — Википедия

Материал из Википедии — свободной энциклопедии

Менеджер паролей — программное обеспечение, которое помогает пользователю работать с паролями и PIN-кодами. У подобного программного обеспечения обычно имеется местная база данных или файлы, которые содержат зашифрованные данные пароля. Многие менеджеры паролей также работают как заполнитель формы, то есть они заполняют поле пользователь и данные пароля автоматически в формах. Обычно они реализованы как расширение браузера.

Менеджеры паролей делятся на три основных категории:

• Десктоп — хранят пароли к программному обеспечению, установленному на жестком диске компьютера.
• Портативные — хранят пароли к программному обеспечению на мобильных устройствах, таких как КПК, смартфон или к портативным приложениям на USB-флеш-накопителе.
• Сетевые — менеджеры паролей онлайн, где пароли сохранены на веб-сайтах провайдеров.

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

Менеджеры паролей обычно используют выбранный пользователем основной пароль, или секретную фразу (passphrase), чтобы сформировать ключ, используемый для зашифровки хранимых паролей. Этот основной пароль должен быть достаточно сложным, чтобы устоять при атаках злоумышленников (например полный перебор).

Если основной пароль будет взломан, то будут раскрыты все хранимые в базе данных программы пароли. Это демонстрирует обратную связь между удобством использования и безопасностью: единственный пароль может быть более удобен, но если он будет взломан, то поставит под угрозу все хранимые пароли.

Основной пароль может также быть атакован и обнаружен при использовании кейлоггера или акустического криптоанализа (acoustic cryptanalysis). Такая угроза может быть снижена путём использования виртуальной клавиатуры, как, например, в KeePass.

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

Менеджер паролей онлайн — веб-сайт, который надежно хранит данные логина. Таким образом это сетевая версия обычного десктоп-менеджера паролей.

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

Главный недостаток онлайн-менеджеров паролей — необходимо доверие хостингу сайта. Неоднократные взломы и потери централизованно хранившейся информации на сервере не внушают доверия.

Существуют смешанные решения. Ряд ресурсов, таких как FortNotes^[1], предоставляющие услуги онлайн-хранения паролей и других секретных данных, распространяют исходные коды этих систем. Возможность провести аудит кода и установить такую систему на защищенный фаерволом сервер или на сервер, не имеющий прямой выход в Интернет, позволяет решить проблему с возможной компрометацией данных.

Использование сетевого менеджера паролей — альтернатива технологии единого входа (Single Sign On), такой как OpenID или Microsoft’s Windows Live ID, и может использоваться как временная мера, пока не будет принят лучший метод.

Также существуют менеджеры паролей с барьерной защитой. В этом случае защищается интернет-аккаунт пользователя в целом. Периметр защиты строится начиная от противодействия клавиатурным и экранным шпионам, и заканчивая защитой от подмены ip-адреса сетевого ресурса. Для сетевой защиты используется Google Public DNS, а противодействие шпионам обеспечивается автоматической подстановкой авторизационных данных в web-формы.

Пять лучших менеджеров паролей по версии Lifehacker.com — Офтоп на vc.ru

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

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

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

LastPass

Издание Lifehacker.com отмечает, что LastPass стал одним из первых менеджеров паролей, которыми было удобно пользоваться для хранения паролей как онлайн, так и локально.

LastPass запоминает пароли пользователя и позволяет заниматься их менеджментом, а также автоматически меняет их, если сервис, для которого они предназначались, был взломан или иным способом скомпрометирован. LastPass поддерживает двухфакторную аутентификацию для хранилища паролей с помощью Google Authenticator, USB-устройства или YubiKey.

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

LastPass поддерживает Windows, OS X, Linux, Android, iOS, Windows Phone и Blackberry, а также плагины для браузеров Chrome, Firefox, Safari, Opera и Internet Explorer. Базовая версия сервиса бесплатна, а премиум-менеджер с максимумом функций и поддержкой мобильных платформ доступен за $12 в год.

Как отмечает издание Lifehacker.com, многие пользователи заявили, что LastPass сделал их жизнь в сети намного проще. Благодаря сервису нет необходимости использовать один и тот же пароль на каждом сайте, не приходится ошибаться в наборе или случайно отправлять комбинации кому-либо. Менеджер позволяет заблокировать важные данные тогда, когда вам кажется, что вас взломали, и мотивирует лучше заботиться о безопасности.

Dashlane

Dashlane был запущен в 2012 году и быстро обрел популярность за счет внимания к интерфейсу, безопасности, простоты автор

Используем passwordstore.org — менеджер паролей в стиле KISS / Habr

Всем привет. В этой статье я хотел бы поделиться своим опытом настройки и использования pass — менеджера паролей для Linux и не только, примечательного своей простотой, использованием уже присутствующих в системе инструментов и возможностью работать исключительно из консоли. Конкретнее, будут затронуты проблемы, связанные с генерацией и хранением секретного ключа gpg, а также с настройкой совместной работы pass, gpg, git, github и браузера. Всё — под Linux, Windows и Android.

Технически pass является очень простой обвязкой над GnuPG и git, написанной на bash. Каждый пароль (и сопутствующая ему информация, например логин) хранится в зашифрованном файле. Поиск нужного пароля осуществляется по имени файла, шифрование — при помощи GnuPG, синхронизация между устройствами — при помощи git.

Кроме оригинального pass есть еще два совместимых с ним популярных проекта, работающих и под Windows:

1. QtPass. GUI-приложение, написанное, как нетрудно догадаться, на Qt.
2. Gopass. Приложение для командной строки, написанное на go. Под Windows я пользуюсь именно им. Однако, на мой взгляд, разработчики начали добавлять туда слишком много лишних фич, при этом отказываясь от интуитивности.

Разработчик pass — Джейсон Доненфельд, также являющийся автором WireGuard (реализации VPN на основе современных стандартов криптографии, «work of art по сравнению с OpenVPN и IPSec» по мнению Линуса Торвальдса, которая скорее всего появится в ядре Linux 5.6).

GnuPG — система для шифрования и электронных подписей. Несмотря на недостатки (вот, например, статья с критикой gpg), она уже больше 20 лет остается де-факто стандартом. Даже статья по ссылке затрудняется назвать альтернативный инструмент для шифрования файлов.

Процесс создания секретного ключа в консоли описан например на habr, но почему бы не сделать это в GUI? В проекте KDE сделали фронтенд для GPG под названием Kleopatra. Пользователи Linux найдут его в репозиториях, а в gpg4win Kleopatra есть из коробки.

В меню выбираем File — New Key Pair — Create a personal OpenPGP key pair.

Вводим имя и email. Не нужно беспокоиться, что в будущем вы их смените. GPG позволяет свободно добавлять к ключу новые uid и удалять существующие. Если хотите подписывать создаваемым ключом свои git-коммиты и видеть плашки «Verified» напротив них, то тут нужно указать реальный email, имеющий статус «подтвержденный» в вашем аккаунте на github.

Далее нажимаем Advanced Settings для настройки параметров ключа.

В разделе Key Material выбираем ECDSA/EdDSA + ECDH. Я предпочитаю использовать не классический алгоритм RSA, а основанные на эллиптических кривых ed25519/cv25519. Их основное преимущество над RSA с точки зрения конечного пользователя — меньший размер ключа при аналогичной криптостойкости. Утверждается, что ключ ed25519 длиной 256 бит примерно такой же стойкий, как ключ RSA длиной 3072 бита. Единственное преимущество последнего — большая распространенность, особенно в аппаратных системах.

В меню еще можно выбрать семейства кривых Brainpool и NIST. Однако вторые подозреваются в наличии бэкдора NSA, и к первым тоже есть небольшие претензии. Поэтому предложенные известным криптографом Даниэлем Бернштейном ed25519 и cv25519 — лучший выбор.

Интересный факт: в активно продвигаемом сейчас стандарте аутентификации FIDO U2F (в разработке которого активно участвовала компания Google) применяются именно кривые NIST. Также, например, в Android Keystore есть их поддержка, но нет поддержки ed25519. Почему так произошло?

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

libsodium).

Если планируете использовать этот ключ для работы с git, то в разделе Certificate Usage нужно отметить пункты Signing и Authentication.

На следующем шаге предлагается придумать пароль, с помощью которого будет защищен ключ. Поскольку ключ будет использоваться для шифрования всех данных в хранилище, этот пароль является мастер-паролем. Стоит подойти к его выбору с особой педантичностью.

Генерация мастер-пароля

Разумеется, всегда можно сгенерировать случайную строку из достаточного (например 20) количества символов. Однако её практически невозможно запомнить и трудно ввести без ошибок, особенно на смартфоне. Поэтому EFF в своем гайде рекомендует вместо этого пользоваться парольными фразами.

Метод работает так: берем достаточно большой словарь (EFF предлагает несколько словарей, например этот) и выбираем из него не менее 6 случайных слов. Выбирать можно как угодно, даже вообще без компьютера при помощи игральной кости или монетки. Такой метод называется diceware. До игральных костей и монеток я еще не дошел, поэтому просто воспользуюсь входящей в состав GNU coreutils утилитой shuf:

$ shuf --random-source=/dev/random -n 6 ./eff_large_wordlist.txt
51345   rendering
24564   edging
65652   vivacious
31343   footprint
55261   snore
24436   earache

Сохраняем эту парольную фразу в надежном месте за пределами компьютера.

В результате будет создан секретный ключ. При работе в консоли часто придётся указывать его fingerprint, стоит записать это число.

Теперь можно настроить интеграцию gpg и git.

Строго говоря, этот пункт не обязателен. Хранилище паролей pass — это просто каталог с зашифрованными файлами, а значит, его можно синхронизировать как угодно. Google Drive, Яндекс.Диск, и т.д. и т.п. Если не хотите использовать git, то советую обратить внимание на Syncthing. Это программа с открытым исходным кодом, которая требует минимум настроек и передаёт файлы напрямую между устройствами, не храня их на сторонних серверах.

В качестве git-хостинга никто не мешает поднять свой собственный сервер, поставив туда например Gitea, однако это означает затраты на его поддержку и не обязательно гарантирует большие безопасность и надежность. Поэтому я, не гнушаясь пользоваться продуктами фирмы Microsoft, просто создал приватный репозиторий на github.

Стандартный механизм аутентификации в git — с помощью SSH. Обычно подразумевается, что для этого нужен специальный ключ ssh. Однако есть возможность, не плодя лишние сущности, использовать созданный на предыдущем шаге ключ gpg. Чтобы gpg-ключ (точнее, подключ) мог использоваться ssh, должны быть выполнены два условия:

1. у него должен быть установлен флаг A — Authenticate;
2. его keygrip должен быть прописан в файле ~/.gnupg/sshcontrol.

Первый пункт уже выполнен, а получить keygrip можно командой

gpg --list-secret-keys --with-keygrip 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7

В выводе gpg нас интересует keygrip подключа ed25519 (05B6641E23D720E87EE6A26020BAB214B842F2B7).

Теперь можно загрузить публичный ключ на github. Заходим в раздел SSH and GPG keys в профиле и выбираем New SSH key. В консоли набираем

$ gpg --export-ssh-key 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPfj81nennAoujvw1fLzGx9iED34zk5oDMYKuUcBq5wv openpgp:0x54068AC7

и копируем получившийся публичный ssh-ключ.

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

$ gpg --export --armor 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7
-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEXcrHrBYJKwYBBAHaRw8BAQdA9+PzWd6ecCi6O/DV8vMbh3IQPfjOTmgMxgq5
RwGrnC+0G0hlbGxvIEhhYnIgPGZha2VAZW1haWwuY29tPoiQBBMWCAA4BQsJCAcC
BhUKCQgLAgQWAgMBAh5BAheAFiEEBgnJ3+8aorON7brcwFRLVVQGiscFAl3WO2wC
GyMACgkQwFRLVVQGiscg5AEAkh0a6OQS2CPiXq9bWB+wULHUGT6NYZhwZ3eUQCfH
Zq0A/iFBJQkAZIFdqH84ksFbvv6K/LQy72NRJzK0tho6qFwHuDgEXcrHrBIKKwYB
BAGXVQEFAQEHQEs6UVOtj5yMGxvRcMU577miH/Bh5kZWMJKHxsDBcXV4AwEIB4h5
BBgWCAAgFiEEBgnJ3+8aorON7brcwFRLVVQGiscFAl3Kx6wCGwwACgkQwFRLVVQG
isea8wD/X5JSJW0PMu/KucytUZZo8obHa86/TUwH/8+xQ3+djuEBALugbQRmCIr5
/JYO7x5PNA0QYqhh7LIZ9nKYp0mhqpcO
=dc89
-----END PGP PUBLIC KEY BLOCK-----

и копируем то, что получилось, в форму New GPG key.
Дальнейшие действия специфичны для используемой операционной системы.

Интеграция gpg и git (linux)

Используемый git клиент OpenSSH может получать ключи двумя способами: из каталога ~/.ssh и через сокет, созданный демоном ssh-agent. В качестве последнего может выступать gpg-agent, чем мы и воспользуемся. В файле ~/.gnupg/gpg-agent.conf нужно прописать строку enable-ssh-support.

Перезапускаем gpg-agent командой

gpg-connect-agent reloadagent /bye

После этого он создаст сокет по адресу

${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh

Этот путь (он может зависеть от дистрибутива) надо прописать в переменной окружения $SSH_AUTH_SOCK, и ssh его подхватит. Набираем в консоли команду

ssh -T [email protected]

и если все прошло успешно, то после ввода мастер-пароля появится сообщение об успешной аутентификации.

Интеграция gpg и git (Windows)

Относительно недавно Microsoft добавила OpenSSH в число доступных для установки компонентов Windows, а также реализовала поддержку сокетов типа AF_UNIX, таких как тот самый SSH_AUTH_SOCK. Тем не менее, Win32-OpenSSH не умеет взаимодействовать с gpg4win, так как до сих пор использует только именованные каналы.

Поэтому придётся установить вечнозелёный Putty. Прописываем в файле

~/AppData/Roaming/gnupg/gpg-agent.conf

строку enable-putty-support и перезапускаем gpg-agent. После этого он начнет прикидываться Pageant — демоном ключей. В той же папке должен быть расположен и файл sshcontrol.

Чтобы git-клиент начал использовать putty, нужно создать переменную окружения GIT_SSH с путем до plink.exe. Например, у меня это

C:\ProgramData\chocolatey\bin\PLINK.EXE

Кстати насчет git. Обычно устанавливающийся клиент git for windows содержит много ненужного (по крайней мере, ненужного для работы gopass), например собственную реализацию OpenSSH. Однако его разработчики делают и более легкие версии, которые можно скачать на github. Например, там есть в 2 раза меньший по размеру MinGit, а рисковые люди могут попробовать и MinGit-busybox. Версия busybox возникла из-за стремления разработчиков создать git-клиент, использующий api Win32 без прослоек вроде MSYS2. Однако, по их же отзывам, mingit-busybox пока содержит много багов. Подробнее об этих усилиях можно почитать в тикете.

Убеждаемся, что gpg-agent запущен (gpg-connect-agent /bye), и проверяем соединение с github:

plink [email protected]

Настройка git

Здесь ничего необычного. Думаю, команды можно привести без комментариев:

git config --global user.name "Hello Habr"
git config --global user.email [email protected]
git config --global user.signingKey 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7

git config --global gpg.program /usr/bin/gpg
git config --global commit.gpgSign true

Пункт gpg.program нужен, если gpg нет в PATH.

Секретный ключ стоит хранить так же надежно, как и парольную фразу, то есть за пределами компьютера. Можно просто распечатать длинную последовательность чисел, но распознавать её или вводить с клавиатуры — занятие не для слабонервных. Поэтому я предпочитаю генерировать QR-код, который легко отсканировать любым смартфоном. Для этого есть специальная программа qrencode. Генерация картинки с QR-кодом выполняется так:

gpg --export-secret-key 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7 | qrencode --8bit --output secret-key.qr.png

Разумеется, чем меньше ненужной информации в бэкапе, тем лучше. Здесь очень кстати приходится небольшой размер ключа ed25519. Спасибо Даниэлю Бернштейну!

Существует специальная утилита paperkey, позволяющая сократить объем данных до предела. Ценой сокращения является то, что секретный ключ из такого бэкапа можно будет восстановить только при наличии публичного. В экосистеме GPG есть специальные сервера для хранения публичных ключей, почитать про них и не только можно в статье https://eax.me/gpg/.

Бэкап paperkey создается следующим образом:

gpg --export-key 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7 > pubkey.asc
gpg --export-secret-key 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7 | paperkey --output-type raw | qrencode --8bit --output secret-key.qr.png

Второе правило бэкапера: бэкап не существует, пока не подтверждена возможность восстановить из него данные. Поэтому проводим стресс-тест. Удаляем секретный ключ командой

gpg --delete-secret-key 0609C9DFEF1AA2B38DEDBADCC0544B5554068AC7

Затем сканируем QR-код и импортируем ключ обратно в GPG. В качестве сканера QR-кодов под Android мне нравится BinaryEye, свободная программа с удобным интерфейсом. На картинке ниже — бэкап секретного ключа из этой статьи.

paperkey --pubring pubkey.asc --secrets from_qr.asc > secretkey.asc
gpg --import ./secretkey.asc

Надеюсь, вы нигде не будете использовать этот ключ. Он создан только для иллюстрации.

Если все работает, то можно двигаться дальше.

Теперь, когда у нас есть надежно сохраненный и защищенный секретный ключ, а также работающая интеграция с git, можно начинать пользоваться собственно pass. Я предпочитаю gopass, так как эта альтернативная обвязка работает под Windows.
Инициализируем хранилище паролей командой

gopass init

и выбираем из списка нужный секретный ключ.

Работа с git происходит так же, как в случае с обычным репозиторием, только в командной строке надо дописывать (go)pass. Инициализируем репозиторий и добавляем туда нужный origin:

gopass git init
gopass git remote add origin [email protected]:xxx/taisho-secrets.git

Адрес можно узнать на странице репозитория на github, нажав кнопку Clone or download.

В gopass есть специфичная команда

gopass sync

выполняющая и git pull, и git push, то есть полную синхронизацию.

Хранилище по умолчанию создается в папке ~/.password-store, но можно указать и свой путь.
Для работы с паролями в консоли поддерживаются команды ls, cp, mv, search, create, и т.п. Полный список можно получить, набрав gopass --help, но лично я 95% времени пользуюсь не консолью, а плагином для браузера.

Интеграция с браузером

Плагин для браузера называется gopass bridge, его можно найти в сторах Chrome и Firefox (см. ссылку).

Для связи плагина с собственно gopass понадобятся вспомогательный скрипт и манифест для native messaging. Они создаются командой

gopass jsonapi configure

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

Проверяем, как все работает. Создаем новый пароль:

gopass new habr

отвечаем на все вопросы и сохраняем. GPG предложит ввести мастер-пароль для работы с секретным ключoм.

Теперь открываем меню плагина с характерным голубым сусликом, и если все прошло успешно, то мы сможем найти там свой пароль.

TOTP-ключи

Лично я пользуюсь FreeOTP, однако с этими ключами можно работать и с помощью pass. Пользователям оригинального pass надо установить расширение pass-otp, а в gopass и APS (см. ниже) нужные функции есть из коробки.

Чтобы добавить TOTP-ключ в хранилище паролей при помощи pass-otp, получаем URL (начинающийся с otpauth://) и вводим команду

pass otp insert totp-secret

Можно ли будет назвать двухфакторной получившуюся аутентификацию — спорный вопрос. Разработчики KeePassXC рекомендуют хранить TOTP-ключи в отдельной базе данных, защищенной другим паролем. В pass так тоже можно сделать.

Реализация GnuPG под Android называется OpenKeychain. Для её настройки достаточно зайти в меню «управление ключами» и импортировать ранее созданный секретный ключ. Единственный недостаток OpenKeychain лично для меня — нет разблокировки по отпечатку пальца.

Реализация pass под Android называется android-password-store, или просто APS.

Устанавливаем и запускаем APS. Прежде чем синхронизировать хранилище паролей, заходим в меню «Настройки». Там нам понадобятся следующие пункты:

1. Настройки сервера git. Получившийся URL должен быть таким же, какой указан на странице репозитория на github. Тип авторизации — OpenKeychain.
2. Git utils. В этом разделе указываем username и email из ключа gpg.
3. Провайдер OpenPGP. Выбираем OpenKeychain.
4. Автозаполнение. Эта совсем недавно появившаяся фича включает заполнение паролей в приложениях на Android 8.0+.

На заметку пользователям смартфонов Huawei, да и всем остальным тоже: OpenKeychain, APS, BinaryEye, FreeOTP, а также Syncthing, Telegram, Tachiyomi, KDE Connect и много чего еще доступны в F-Droid. Пользователи Google Play должны это оценить: каталог ПО, в котором нет рекламы, руткитов, и просто мусорного софта из известной статьи tonsky.

До появления автозаполнения в APS я пользовался keepass2android. Её нет в F-Droid по оригинальной причине: она написана на Xamarin, но мейнтейнеры F-Droid вот уже 9 месяцев как не могут установить этот фреймворк на свой сборочный сервер. Кто-нибудь, сделайте что-нибудь.

Теперь можно клонировать. Выбираем на главном экране «клонировать с сервера», указываем желаемое расположение хранилища, проверяем настройки git.

Если попытка работы с git приведет к ошибке (это было вероятно в предыдущих релизах APS из-за использования устаревшей версии библиотеки jgit от проекта Eclipse), то по-прежнему есть Syncthing.

Конечно, pass не так просто настроить. Однако за эту цену покупается уверенность, что используемые нами (а также людьми вроде Линуса Торвальдса или Эдварда Сноудена) инструменты в один прекрасный момент не будут объявлены устаревшими, не сменят формат данных и не окажутся без поддержки. А если и окажутся, то простая модульная архитектура pass поощряет создание каких угодно альтернативных клиентов и расширений.

Если вы решите не использовать pass, то, надеюсь, некоторые упомянутые в статье программы окажутся вам полезными и сами по себе.

Менеджер паролей с web доступом / Habr

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

Выбор софта был осложнён тем, что требовалось решение с возможностью установки на локальный сервер и именно под Linux. Наконец после долгого поиска мною был установлен и опробован TeamPass — Collaborative Password Manager. Данный продукт полностью удовлетворил мои потребности в централизованном хранения паролей. Я не буду описывать установку. Она довольно простая и достаточно подробно описана тут. Моей целью было рассказать про решение которое я долго искал. Авось кому-нибудь тоже пригодится.

Первое что нас встречает, окно авторизации в котором можно установить временной лимит сеанса. По умолчанию он ограничен 60 минутами, но это значение можно поменять.

Если выбранного времени вам оказалось мало, вы можете легко продлить сессию.

Основной, рабочий интерфейс программы функционально разделён на две панели. В левой — ресурсы, в правой — содержимое ресурсов с паролями. Для операций создания и редактирования служит панель в крайней правой части окна. Для настроек и управления программой — верхняя панель. Интерфейс почти полностью переведён на русский язык. Правда в переводе встречаются ошибки, но их легко поправить в файле includes/language/russian.php

Пользователю доступны три основных уровня прав: Администратор (в интерпретации TeamPass Бог :)). Менеджер — может создавать папки и заводить пароли в пределах разрешённых каталогов. И простой пользователь Read Only, который может только смотреть разрешённые объекты, но не может ничего изменять.

На вкладке «Управление ролями» можно настроить видимость папок для группы пользователей.

К самой структуре хранения пришлось несколько приспособиться. Лично мне необходимо хранить пароли для серверов, а паролей может быть несколько. Поэтому хранение было организовано таким образом: сам сервер является папкой, а уже пароли объектами.

Посмотреть скрытый пароль можно нажав кнопку с изображением глаза.

Пароли можно генерировать в самой программе выбирая желаемый уровень сложности.

Также при создании папки можно принудительно установить сложность будущих паролей. Пользователь не сможет создать пароль более простого уровня.

Из личных ощущений. Конечно программа не без шероховатостей, но в целом доволен. Если кто-то подскажет более достойный вариант, буду более чем признателен.

В конце маленькое замечание. Т.к. сервер будет содержать ценнейшие сведения, настоятельно рекомендую позаботиться о его безопасности. Установить сложный пароль на вход, отключить пользователя admin, не выпускать сервер в интернет, давать доступ ограниченному кругу лиц. Не поленитесь прикрутить SSL сертификат. Причем не самоподписной, а доверенный. Тем более что есть способ получить его бесплатно. Не лишним, я бы даже сказал обязательным, будет прогнать сервер через тесты сканеров безопасности, например Nessuss или Metasploit.

UPD: Зоркий глаз уважаемого UksusoFF отметил возможность импорта из файла CSV или KeePass XML.

Пастильда — открытый аппаратный менеджер паролей / Habr

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

• закрытый код снижает доверие и вероятность оперативного устранения уязвимостей
• для автозаполнения нужно ставить дополнительный софт
• после ввода мастер-пароля вся база открыта и доступна, в том числе для вредоносного ПО, что особенно актуально на недоверенных устройствах
• использование мобильных приложений для хранения паролей все равно подразумевает ручной ввод с клавиатуры, например когда требуется залогиниться на стационарном ПК
• автозаполнение невозможно в некоторых случаях (в bios, консоли)

Мы пришли к выводу, что наиболее удобным решением будет простой и недорогой девайс, позволяющий аппаратно хранить и вводить логины/пароли на любые устройства, без установки какого-либо ПО.

Для начала мы, конечно же, прочитали весь интернет, чтобы понять, кому еще приходила в голову идея хранить и вводить пароли аппаратно, и как она была реализована. Найденные варианты можно условно разделить на следующие категории:

• шифрованные накопители, по сути — просто флешки с паролем (например, такая). Можно безопасно хранить документы, но об автоматическом вводе паролей речь не идет
• устройства с биометрической идентификацией (пример). Биометрическая идентификация выглядит привлекательно, однако она менее универсальна, чем символьный пароль (например, если надо удаленно предоставить кому-то доступ к устройству, передача отпечатка пальца станет настоящей проблемой), к тому же дополнительные датчики увеличивают стоимость изделия. В случае компроментации сложно быстро сменить отпечатки
• программные менеджеры паролей с аппаратным ключом-токеном, который дает доступ в базу (например) обладают теми же недостатками, что и программные менеджеры без ключа-токена
• устройства для ввода 1-4 паролей и их генерации (пример, пример). Наиболее близкие решения. Из недостатков следует отметить ограниченное количество хранимых паролей а также управление исключительно кнопками на устройстве, что далеко не всегда удобно.

Ни одно из найденных устройств в полной мере не соответствовало нашей задумке. Мы обрадовались — и давай думать дальше.

Идея

Не так давно для корпоративных задач хранения паролей вместо бумажек, браузеров и биологической памяти мы стали использовать KeePass. Вполне довольные удобством и универсальностью этого продукта, мы решили приспособить его для задач аппаратного хранения паролей, портировав на микроконтроллер.
Однако, осталось огромное количество вопросов. Каким образом выбирать нужную запись в базе на устройстве? Как показать пользователю, какая запись выбрана? Стоит ли размещать на корпусе устройства кнопки? Экран? Как вообще оно должно подключаться к компьютеру? К планшету? К телефону?

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

Для управления мы будем использовать стандартную клавиатуру, а для непосредственного ввода сохраненных паролей в формы — эмулировать клавиатурные команды. “Перехват” управления будет происходить при вводе специальной комбинации клавиш. По умолчанию мы выбрали сочетание Ctrl + Shift + ~, потому что оно удобно для нажатия и практически нигде не используется. Проект получил название “Pastilda” (от password, tilda), у нас оно ассоциируется с чем-то вкусным и сладким, а также помогает не забыть главное сочетание клавиш для работы с устройством.

Находясь в пассивном режиме Пастильда транслирует все сообщения от клавиатуры к ПК без изменений, ожидая нажатия специальной комбинации. После ввода комбинации устройство входит в активный режим. Если в этот момент курсор находится в поле для ввода текста — это может быть поле “Логин”, или любое другое текстовое поле — в нем появляется одно-строчное текстовое меню.

Для работы с базой KeePass, хранящейся в памяти Пастильды, пользователь вводит мастер-пароль, а затем при помощи навигационных клавиш выбирает название интересующего его аккаунта и нажимает ввод. Пастильда вводит нужные логин и пароль в соответствующие поля. При этом расшифровка базы происходит на устройстве, и целевая система не получает доступа к мастер-паролю и ко всей базе. Выход из активного режима происходит либо автоматически, после ввода пароля, либо после повторного нажатия комбинации “Shift + Ctrl + ~”. Да, кстати, комбинации можно придумать свои.

Реализация 0.1

Как всегда много чего хочется реализовать, а начать решили с малого. Ревизия 0.1 предназначена для проверки идей, удобства использования и всяческого баловства. В текущей версии запланирован следующий минимум функций:

• составное USB устройство (HID+Mass Storage)
• USB host
• работа с одной базой KeePass
• однострочное меню
• FAT16.

Схема

Тут всё просто — контроллер Stm32f405, два разъема и флешка на SPI. Так же немного защиты, разъем SWD и, конечно же, RGB светодиод. Выбор компонентов не вызвал затруднений — STM мы просто любим, похоже, единственный, кто реализовал два аппаратных USB в микроконтроллере, а память взяли какая была.

Плата

Все компоненты в обычных корпусах, чтобы плата была дешевая и быстрая в производстве. Размер 40х17 мм, 4 слоя. Текущая версия платы выглядит вот так:

Софт

На данный момент реализовано:

• USB host, для того чтобы распознавать подключенную к устройству клавиатуру и прокидывать сообщения от нее дальше в ПК
• составное USB устройство (msd + hid): в режиме Pastilda устройство должно уметь быть клавиатурой, кроме того, быть всегда доступным как внешний диск, для удобного добавления и удаления паролей (Попутно @anaLazareva решила проблему с usb_msc libopencm3.

Ждет своей участи:

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

О своих суровых буднях программисты напишут в отдельных статьях.

Что дальше?

Дальше — больше. Хочется реализовать работу с любыми устройствами, понимающими внешнюю клавиатуру. Мы уже протестировали работу нашего прототипа с Android-смартфоном через USB OTG, всё работает прекрасно. Для удобства навигации по меню при использовании Пастильды с мобильными устройствами сделаем отдельный USB-модуль с колесом-кнопкой.

Ещё одна идея — маленькая гибко-жесткая печатная плата, которая заправляется прямо в разъем USB, оказываясь между контактами host и device. Жесткий кусочек платы с компонентами наклеивается на корпус штекера device. Таким образом устройство будет довольно сложно обнаружить. Впрочем, зачем бы нам это? Просто идея.

Встроенную память Пастильды можно использовать для хранения данных (если скорость не особо важна), и тут возможны варианты: просто USB накопитель, который виден всегда, когда устройство подключено, либо шифрованный накопитель. Базы KeePass, файлы ключей и т.п. предполагается хранить на этом пространстве.

Open all

Код выложен на github, вместе с железом. Лицензия GNU GPL. Естественно, можно пилить что-то свое на основе этого проекта, нам в голову пришли такие идеи:

• эмуляция kbd+mouse для гейм-читинга
• потоковое аппаратное шифрование USB-флеш.

Главная цель этой статьи — услышать ваше мнение, не стесняйтесь в комментариях!

UPD 27.06.2017:

• Репозиторий проекта Пастильда переехал сюда. Недавно был опубликован релиз 1.0.
• Последние новости по проекту можно смотреть здесь.
• А еще мы наконец-то запустили сайт проекта!

Достаём мастер-пароль из заблокированного менеджера паролей 1Password 4 / Habr

Новые инструменты, старые методы. Проводим обратную разработку и находим фатальный недостаток 1Password.

Все любят менеджеры паролей. Они великолепны по многим причинам. Лично у меня в менеджере более 200 записей. С таким большим количеством конфиденциальных данных в одном месте важно понимать масштаб ущерба в случае компрометации вашей записи, будь то вредоносные программы, эксплоиты или просто компьютер, оставленный без присмотра на несколько минут. Washington Post недавно опубликовала статью, основанную на нашем исследовании. Эта статья помогает довести людей, что не все менеджеры паролей одинаковы.

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

Это верно для 1Password 4 (Обратите внимание, что последняя версия на сегодня седьмая). Прежде чем перейти на него несколько лет назад я проверил, что в памяти действительно нет паролей в открытом виде, когда менеджер в заблокированном состоянии. Так что в случае компрометации злоумышленнику придётся иметь дело с зашифрованным хранилищем.

Хранилище заперто!

В этом состоянии в памяти нет ни парольных записей, ни мастер-пароля. Очень разумно и правильно, и 1Password 4 прошёл эту проверку. Или нет?

Чтобы избавить от скучных деталей, скажу сразу: мы смогли восстановить мастер-пароль из заблокированного инстанса в 1Password 4, как показано ниже.

Разблокировка 1Password 4 и восстановление мастер-пароля

В анимации показано, что 1Password 4 сначала разблокируется нормальным способом, а затем запирается. После этого мы запускаем нашу утилиту multipass, которая успешно восстанавливает пароль. Утилита эксплуатирует неправильную обработку поля ввода пароля в 1Password 4, чтобы восстановить обфусцированный буфер мастер-пароля, деобфусцировать его, автоматически разблокировать 1Password 4 и, наконец, отобразить мастер-пароль в консоли.

Первый шаг при оценке менеджера паролей: проверить наличие мастер-пароля в памяти в открытом виде. Это возможно в любом hex-редакторе, который способен взаимодействовать с пространством памяти процесса. Например, бесплатный редактор HxD. С его помощью можно открыть пространство памяти 1Password 4.

Мы сразу попадаем в первую читаемую область пространства памяти 1Password 4.

Пример представления памяти HxD

Пока ничего особенного. Но можно выполнить поиск. Например, как выглядит ситуация, если набрать пароль в окне разблокировки 1Password 4, но не нажать кнопку «Разблокировать»:

Запертое хранилище 1Password 4 с введённым мастер-паролем в поле

Наверняка пароль где-то в памяти?

Открываем HxD, но поиск строки с нашим мастер-паролем (“Z3Superpass#”) не даёт результатов.

Похоже, 1Password как-то шифрует или обфусцирует форму по мере её ввода. Если процедура работает правильно, то всё хорошо.

Чтобы узнать, почему мастер-пароль нельзя найти в памяти, когда он явно присутствует в диалоговом окне разблокировки, следует найти код, который с ним взаимодействует. Тут есть несколько способов. Можно отследить обработку событий клавиатуры и мыши путём локализации ‘GetMessage’, ‘PeekMessage’, ‘GetWindowText’ или других Windows API, которые обычно обрабатывают пользовательский ввод. Так мы найдём буфера, куда записываются нажатия клавиш, а через них выйдем на подпрограмму шифрования/обфускации. Но это долгий и подверженный ошибкам процесс, особенно с большими фреймворками, которые иногда очень странно управляют памятью, так что для отслеживания буфера придётся сделать множество копий и преобразований.

Вместо этого используем собственный инструмент Thread Imager, созданный для обратной разработки «странных» проприетарных протоколов на прикладном уровне. Он поможет определить, в каком месте памяти 1Password 4 взаимодействует с нашим мастер-паролем. Инструмент «автоматически» идентифицирует области кода в 1Password 4, которые взаимодействуют с обфусцированным паролем (он просто подсвечивает инструкции, которые взаимодействуют с интересующими данными, для дальнейшего анализа). Результат выглядит примерно так:

Thread Imager находит код 1Password 4, который взаимодействует с необфусцированным мастер-паролем

Поскольку мастер-пароль хранится в памяти в обфусцированном виде, то инструмент должен первым делом показать, в каком месте происходит обфускация.

Фрагмент из первого результата показывает, что первое появление мастер-пароля сопровождается переходом кода с адреса 0x7707A75D на 0x701CFA10.

Подробная запись в Thread Imager подсвечивает переход кода с с 0x7707A75D на 0x701CFA10, при этом на буфер с мастер-паролем ссылаются регистры EAX и ECX

Изучение этого места 0x7707A75D в отладчике (x64dbg) подтверждает нашу теорию. Действительно, впервые строка ‘Z3superpass#’ встречается при завершении работы функции декодирования ‘RtlRunDecodeUnicodeString’ из библиотеки ntdll.dll.

После небольшого анализа ясно, что для обфускации пароля используются именно эти две функции: ‘RtlRunEncodeUnicodeString’ и ‘RtlRunDecodeUnicodeString’. Так мастер-пароль прячут от примитивного копирования из памяти, вот почему раньше мы не могли найти его в hex-редакторе.

Если изучить закодированный буфер в конце работы функции RtlRunEncodeUnicodeString, то зашифрованная строка с мастер-паролем выглядит так:

Зашифрованный мастер-пароль

После RtlRunDecodeUnicodeString’ он декодируется:

Расшифрованный мастер-пароль

Интересно, что эта область сохраняется по тому же адресу 0x00DFA790 и мы буквально можем наблюдать её изменение при вводе пароля в окно разблокировки 1Password 4:

‘RtlRunEncodeUnicodeString’ и ‘RtlRunDecodeUnicodeString’ — простые функции, которые изменяют строку простой операцией XOR. Это не так уж плохо: похоже, это стандартный метод маскировки всех нативных редактирующих управляющих элементов Windows при установленном флаге ‘ES_PASSWORD’.

Проблема в том, что после разблокировки 1Password 4 зашифрованный мастер-пароль не очищается из памяти.

Хуже того, он остаётся в памяти и после блокировки 1Password 4. То есть у нас есть заблокированное хранилище паролей, но с зашифрованным мастер-паролем в памяти.

И что ещё хуже, поскольку мы взаимодействуем с диалоговым окном ввода мастер-пароля, одна и та же область памяти повторно используется вместе с тем же значением XOR, что даёт нам лёгкий доступ к закодированному буферу для создания эксплоита.

Чтобы создать надёжный эксплоит для 1Password 4, нужно получить более чёткое представление, как мастер-пароль обрабатывается рабочими процессами программы. С помощью вышеупомянутых инструментов мы построили диаграмму выходных данных (рисунок ниже).

По такой диаграмме легче понять, где и какие задействуются библиотеки, чтобы надёжно идентифировать области в памяти, откуда можно извлечь мастер-пароль.

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

Чтобы извлечь его, нужно вызвать процедуру в 1Password 4, которая инициирует ‘RtlRunEncodeUnicodeString’ и ‘RtlRunDecodeUnicodeString’. Таким образом она покажет расположение буфера памяти с закодированным мастер-паролем.

Область памяти с обфусцированным мастер-паролем

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

Похоже, единственный способ вызвать ‘RtlRunEncodeUnicodeString’ и ‘RtlRunDecodeUnicodeString’ — это ввести в символ в диалоговое окно ввода мастер-пароля. Так мы получаем нужный буфер. Но мы не знаем длину пароля.

Мы решили эту проблему путём перехвата кода, который обращается к первому символу нашего буфера, блокируя попытку изменения. Эта подпрограмма находится в цикле обработки сообщений управляющего элемента в comctl32, который обрабатывает управление буфером соответствующих элементов. Вызов ‘memmove’ со смещением 0x70191731 перезаписывает буфер введённым символом:

(Побочный эффект: выделенная строка (жёлтая) обновляет всю строку пароля)

Теперь мы, наконец, получили всё, что нужно для создания эксплоита. Следующие шаги позволят нам извлечь мастер-пароль:

1. Хук ‘memmove’, чтобы предотвратить перезапись первого байта мастер-пароля.
   
2. Хук ‘RtlRunEncodeUnicodeString’, чтобы получить расположение буфера обфусцированного мастер-пароля.
   
3. Хук ‘RtlRunDecodeUnicodeString’ для обращения к обфусцированному буферу, полученному на предыдущем этапе.
   
4. Ввод символа в поле ввода пароля и отказ от шага 1 (сохранение всего мастер-пароля), перенаправление шага 2 на шаг 3 для декодирования обфусцированного мастер-пароля.

Для выполнения всех этих действий создаём DLL с кодом обработчика всех этих хуков. Библиотека внедряется в процесс 1Password 4, отправляет один символ в диалоговое окно мастер-пароль, запуская шаги memmove, RtlRunEncodeUnicodeString и RtlRunDecodeUnicodeString, которые мы можем перехватить — и производя нашу магию по восстановлению обфусцированного мастер-пароля. Большая часть магии происходит в DetourRtlRunEncodeUnicodeString, это хук для функции ‘RtlRunEncodeUnicodeString’, показанный ниже:

Что приводит нас к окончательному результату: разблокировка запертого хранилища 1Password 4 любой версии при помощи глючной процедуры в используемых Windows API:

Когда мы впервые углубились во внутренности 1Password 4, то ожидали встретить какую-то сложную систему защиты и ожидали, что вся секретная информация будет очищаться из памяти, как это происходит в процедурах PBKDF2 и других областях, где используется мастер-пароль. Соответствующие записи тоже очищаются. Однако по недосмотру поле ввода пароля рассматривается как стандартный элемент управления Windows API со скрытым паролем, что подрывает безопасность 1Password 4.