By web3ru research — 18 дек. 2025

PearPass – как устроен менеджер паролей от создателей USDT (Tether)?

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

На этом фоне Tether (эмитент USD₮/USDT) 17 декабря 2025 объявил PearPass — менеджер паролей с синхронизацией peer-to-peer, который, по заявлению компании, держит данные на устройствах пользователя, а не в облаке. (Tether)

Ниже — разбор без рекламного дыма: что именно Tether выпустил, на каком стеке это работает, какие реальные плюсы/минусы даёт P2P‑подход, и как это проверить, а не «поверить на слово».

Что такое PearPass (в двух абзацах)

PearPass — это «local‑first» менеджер паролей: основное хранилище живёт локально, а синхронизация между вашими устройствами идёт через P2P‑соединение. Tether позиционирует его как решение, которое «убирает зависимость от облачных серверов и посредников» и тем самым снижает класс рисков, связанных с массовыми утечками из централизованной инфраструктуры. (Tether)

По документации PearPass:

бесплатный;
поддерживает P2P‑синхронизацию между устройствами;
заявляет использование криптографических примитивов Libsodium;
и подчёркивает, что это open-source. (docs.pass.pears.com)

Почему Tether вообще лезет в менеджеры паролей

Если коротко: Tether уже несколько лет вкладывается в стек P2P‑приложений. Ещё в июле 2022 Tether, Bitfinex и Hypercore объявляли Holepunch как платформу для полностью зашифрованных P2P‑приложений и рассказывали про «Distributed Holepunching» (поиск и соединение пиров в «рои/свармы» на домашних и офисных сетях, с авторизацией через криптографические ключи).
Тогда же в отраслевых публикациях фигурировала оценка финансирования порядка $10 млн на развитие.

PearPass логично ложится в эту линию: ещё одно приложение поверх того же набора «кирпичиков» (Hypercore/Hyperswarm и т.д.), только теперь — для паролей.

Контекст: «облако» — это не зло, но это точка концентрации риска

Важно не впадать в крайности. Современные облачные менеджеры паролей часто используют zero‑knowledge подход: провайдер хранит зашифрованный сейф и (в идеале) не знает ключей. Это сильно снижает риск «админ в компании прочитал ваши пароли».

Но остаётся класс рисков, которые плохо лечатся организационными мантрами:

массовая экспроприация зашифрованных vault’ов (и дальнейшие атаки на слабые master‑пароли);
ошибки реализации, утечки метаданных, баги в бэкапах/интеграциях;
инциденты на стороне поставщика (компрометированные ноутбуки, DevOps‑цепочки, доступы к хранилищам и т.д.).

История LastPass как раз про то, что «zero‑knowledge» не отменяет последствий, если атакующий забирает зашифрованные сейфы и начинает давить на пользователей (фишинг/социнженерия) и на их слабые master‑пароли. В 2024–2025 расследования и публикации связывали крупные кражи криптоактивов (включая эпизод на ~$150 млн) с данными из украденных хранилищ LastPass. (krebsonsecurity.com)

Отдельно: «утечки на миллиарды паролей» в новостях часто оказываются не «взломом одной компании», а компиляциями старых утечек + данными от infostealer‑малвари. Например, Cybernews описывал массивы на миллиарды записей именно в таком ключе (агрегации/сливы/инфостилеры). (Cybernews)

PearPass бьёт не по всей проблеме (пароли всё равно могут утечь с заражённого ПК), но по одному конкретному классу: «центральный поставщик — единая цель».

Главная идея PearPass: убрать сервер как «точку массового поражения»

У PearPass меняется модель угроз:

В облачной модели атакующий мечтает взломать провайдера и «одним ударом» получить миллионы зашифрованных сейфов (а затем выбирать самые слабые цели).

В P2P/local‑first модели «центрального склада сейфов» нет. Значит, массовая кража «всех vault’ов сразу» становится существенно сложнее как операция.

Но плата за это — перенос ответственности на пользователя: безопасность устройств, резервное копирование, дисциплина с мастер‑паролем и т.д. Это нормальный trade‑off, просто его нужно проговорить заранее, а не в момент беды.

Как это устроено технически

Ниже — схема на уровне «достаточно глубоко, чтобы понять, за что вы платите риском».

1) Данные живут в локальном хранилище, синхронизация — P2P

Документация PearPass описывает продукт как local‑first с peer‑to‑peer синхронизацией между вашими устройствами. (docs.pass.pears.com)

Мобильный репозиторий (как минимум README) перечисляет типичные функции менеджера паролей: хранение паролей/заметок/карточек, биометрическая аутентификация, офлайн‑доступ и кросс‑платформенная синхронизация. (GitHub)

2) «Приглашение/инвайт» — это ключевой UX‑механизм добавления устройства

Внутренняя библиотека lib‑pear‑pass (форк holepunchto/autopass) показывает базовую механику: на одном устройстве создаётся invite, и другое устройство «парится» по нему, чтобы стать участником и получать данные. (GitHub)

Это не «логин по e‑mail», а скорее capability‑подход: у кого есть корректный инвайт/ключи — у того есть доступ.

В экосистеме Holepunch есть компонент blind‑pairing-core, который описывает flow pairing’а: инвайтер создаёт приглашение и делится { discoveryKey, seed }, кандидат подписывает/шифрует запрос, член расшифровывает и подтверждает, в ответ может прийти { key, encryptionKey } для доступа к «комнате/данным».

Важный смысл: это не «магическая ссылка», а протокол с криптографической проверкой, где владение ключом доказывается.

4) Почему здесь всплывает Hypercore (и при чём тут Merkle‑деревья)

Стек Holepunch строится вокруг Hypercore — распределённого append‑only лога. Hypercore прямо в README говорит, что он:

поддерживает sparse replication (можно скачивать не всё подряд);
и использует signed merkle trees для проверки целостности лога в реальном времени.

Также в README есть важные детали:

manifest указывает hash: 'blake2b';
подписи по умолчанию — ed25519;
существует discoveryKey, производный от публичного ключа, который можно использовать для поиска/анонса пиров без утечки основного ключа;
и есть опция encryption: { key: buffer } для шифрования блоков.

Если перевести на человеческий: данные можно реплицировать между устройствами частями, а подлинность проверяется криптографически (Merkle‑деревья + подписи). Это полезно в P2P‑среде, где вы не хотите «верить сети на слово».

Криптография: что реально подтверждается источниками

Транспортное шифрование соединений

В стеке Hyperswarm есть модуль @hyperswarm/secret-stream, который прямо описан как:

«Secret stream backed by Noise and libsodium's secretstream»
payload’ы шифруются через libsodium secretstream
рукопожатия по умолчанию используют ed25519
поддерживаются Noise‑pattern’ы (например, pattern: 'XX').

Это хороший признак, потому что:

Noise — это формальный криптографический фреймворк для протоколов рукопожатия/шифрования;
libsodium — широко используемая библиотека.

Но честная ремарка: «используем хорошие кирпичики» ≠ «всё идеально». Поэтому следующий пункт важнее.

Шифрование хранилища и ключевая модель

Tether в анонсе пишет про «криптографические примитивы Libsodium» и подчёркивает, что восстановление «включается ключами пользователя, а не внешними системами». (Tether)
Документация PearPass при этом отдельно и жёстко говорит: master password нигде не хранится, и опции “Forgot Password” нет. (docs.pass.pears.com)

Вывод (без мистики):

есть локальный мастер‑ключ/мастер‑пароль, который держит безопасность vault’а;
«восстановление» в их словаре — это, скорее, сценарии вида «у меня есть устройство A, добавлю устройство B по инвайту», а не «напишу в поддержку и верну доступ по e‑mail».

Open-source: что именно открыто и под какой лицензией

Tether заявляет, что PearPass «fully open-source» и «every component is open-source under Apache 2.0». (Tether)

Проверяемо руками:

tetherto/pearpass-app-mobile — мобильное приложение, лицензия Apache‑2.0, README с функциями и инструкциями сборки. (GitHub)
tetherto/lib-pear-pass — библиотека (форк holepunchto/autopass), Apache‑2.0; README показывает invite/pair flow. (GitHub)

Это важный момент: «open-source» здесь не про «мы где-то выложили одну библиотеку», а про публичные репозитории, которые можно собрать/прочитать.

Независимый аудит Secfault: что нашли и что это значит на практике

На сайте PearPass опубликован финальный отчёт аудита от Secfault Security (PDF).
Сам отчёт описывает white‑box подход (аудиторам дали детали решения заранее), ручной code review, динамическое тестирование и отдельный фокус на криптопримитивах и логике (не только на «вот вам сканер»).

Что нашли (по таблице результатов):

Directory Traversal в обработке invite‑кодов (эксплуатируемость Medium, impact High)
DoS в функциональности импорта (Medium/Medium)
слабая проверка CORS‑Origin (Observation, Low)

И ключевая строка, которую обычно прячут под ковёр, но тут она прямо в отчёте: «All of the identified issues have been mitigated by Tether by the time of this documentation.»

Дополнительно в разделе наблюдений есть история про локальный DoS через IPC/сокет‑мост между расширением браузера и десктоп‑приложением (то есть, если на машине уже есть вредонос, он может попытаться взаимодействовать с этим мостом).

Как это правильно интерпретировать:

аудит не доказывает «взломать невозможно»;
но показывает, что продукт уже прошёл боевую проверку «люди ищут реальные баги», и команда эти баги закрывает.

Важный момент про «без облака»: что именно исчезает, а что остаётся

Исчезает (или резко усложняется):

классическая «массовая кража vault’ов с серверов провайдера»;
риски, связанные с хранением ваших сейфов/бэкапов у третьей стороны.

Остаётся (и это честно важно):

риск компрометации вашего устройства (малварь, расширения, трояны, физический доступ);
риск слабого master‑пароля (и тут никакая архитектура не спасёт);
P2P‑реальность: чтобы синхронизироваться, ваши устройства должны уметь находить друг друга через сеть (для этого используется DHT/свармы и криптоключи).
и, как следствие, возможны ограничения по удобству (например, «нет центра, который синхронизирует, пока ваше второе устройство выключено» — зависит от того, сколько у вас пиров и как часто они онлайн).

Чем PearPass может быть лучше других (без «наш продукт лучший»)

Сравнивать надо не «кто круче», а какую угрозу вы хотите минимизировать.

Если вы боитесь именно “поставщика‑центра”

PearPass убирает саму идею «серверного склада» сейфов. По задумке это делает массовые эксфильтрации сложнее, потому что нечего «вынести из дата‑центра». (Tether)

Если вы боитесь “внутри устройства”

Тут PearPass не магия. Если на вашем компьютере живёт инфостилер, он может украсть данные до шифрования (через кейлоггер) или вытащить доступ из процесса/памяти. Это проблема любого менеджера, даже самого идеального.

Если вам важно восстановление доступа

Тут нужно быть готовым к строгой цене: PearPass говорит, что Forgot Password нет. (docs.pass.pears.com)
У многих облачных решений есть корпоративные recovery‑механики или хотя бы «служебные» сценарии восстановления (со своими рисками). PearPass сознательно идёт другим путём.

Практика: платформы и функции, которые можно “пощупать”

Документация содержит страницу установки с перечнем поддерживаемых платформ.
Мобильный README перечисляет ключевые функции: офлайн‑доступ, генератор паролей, анализ сложности, биометрию и т.д. (GitHub)

Как проверить всё это самостоятельно (без веры в пресс‑релизы)

Ниже — базовый чек‑лист «для взрослого человека с любопытством». Никакого reverse engineering уровня спецслужб.

1) Проверить открытый код и лицензии

Открываете репозитории (мобильный, десктопный, библиотека).
Смотрите лицензии (Apache‑2.0) и историю коммитов. (GitHub)

2) Проверить крипто‑кирпичики

На уровне стека: @hyperswarm/secret-stream документирует Noise + libsodium secretstream и ed25519 handshake.
Hypercore документирует signed merkle trees, blake2b, ed25519, discoveryKey и опции шифрования блоков.
Это не «доказательство безопасности», но это «доказательство, что заявленный стек реально существует и так задуман».

3) Прочитать аудит (а не только заголовок)

В отчёте есть список конкретных находок (directory traversal, DoS, CORS) и фраза о том, что они закрыты к моменту финальной версии документации.

4) Проверить сетевое поведение

Самый простой пользовательский эксперимент:

ставите приложение,
подключаете второе устройство,
смотрите сетевые соединения (например, системным мониторингом/фаерволом/трафиком),
и проверяете, есть ли постоянные обращения к «центральному API» для ваших vault‑данных.

В P2P‑стеке «служебный» сетевой трафик (поиск пиров в DHT) возможен и нормален, но это не должно выглядеть как «ваши vault’ы регулярно уходят на один домен».

5) Проверить “точку невозврата”: восстановление

Документация прямо говорит, что Forgot Password нет. (docs.pass.pears.com)
Поэтому тестируйте заранее:
«если я потеряю устройство и забуду master‑пароль — что произойдёт?»
Ответ должен быть понятен до того, как это случится.

Итоги

PearPass — это не «ещё один менеджер паролей», а попытка поменять архитектурную ось: вместо облака — P2P, вместо аккаунта и серверной синхронизации — добавление устройств через криптографическое pairing’приглашение. Это подтверждается и официальным анонсом Tether, и документацией, и открытыми репозиториями. (Tether)

Сильные стороны подхода:

меньше шансов на «массовую эксфильтрацию vault’ов из одного места»;
открытый код и внятный P2P‑стек (Hypercore, Noise+libsodium secretstream);
наличие независимого аудита с конкретными находками и фиксом.

Слабые стороны (не баги, а цена архитектуры):

нет “Forgot Password” — ответственность за мастер‑доступ и резервирование на вас; (docs.pass.pears.com)
безопасность упирается в здоровье ваших устройств;
удобство синхронизации и «постоянная доступность» могут отличаться от облачных решений — потому что это другая модель.

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

Основные источники

Анонс Tether о запуске PearPass (17 Dec 2025). (Tether)
Официальная документация PearPass (docs.pass.pears.com): обзор, установка, мастер‑пароль. (docs.pass.pears.com)
Репозитории на GitHub (пример: мобильное приложение и библиотека lib‑pear‑pass, Apache‑2.0). (GitHub)
Аудит Secfault Security (Final report, PDF): методология, таблица находок, закрытие проблем.
Компоненты стека Holepunch/Pears: Hypercore (signed merkle trees, discoveryKey, blake2b/ed25519), secret-stream (Noise + libsodium).
Истоки Holepunch (Tether/Bitfinex/Hypercore, 25 Jul 2022) и описание distributed holepunching/DHT.
Контекст по рискам: расследования/публикации о последствиях утечек LastPass и связанных кражах, плюс материалы о больших «компиляциях» слитых учётных данных (infostealers/агрегации). (krebsonsecurity.com)