КРОССПЛАТФОРМЕННАЯ СИСТЕМА ЗАЩИЩЁННОГО УПРАВЛЕНИЯ АУТЕНТИФИКАЦИОННЫ-МИ ДАННЫМИ НА БАЗЕ АРХИТЕКТУРЫ ZERO-KNOWLEDGE

CROSS-PLATFORM SECURE AUTHENTICATION DATA MANAGEMENT SYSTEM BASED ON THE ZERO-KNOWLEDGE ARCHITECTURE

Dreyman Artem Edgarovich

Student, Department of Cybernetics and Information Security, Moscow Technical University of Communications and Informatics,

Russia, Moscow

Losev Ilya Konstantinovich

Student, Department of Cybernetics and Information Security, Moscow Technical University of Communications and Informatics,

Russia, Moscow

Maximova Elena Alexandrovna

Scientific supervisor, Doctor of Technical Sciences, Associate Professor, Moscow Technical University of Communications and Informatics,

Russia, Moscow

АННОТАЦИЯ

Проблема компрометации пользовательских учётных данных остаётся одной из наиболее острых в современной информационной безопасности: по данным отраслевых отчётов за 2025-2026 годы, свыше 80% успешных взломов аккаунтов обусловлены использованием слабых либо повторно применяемых паролей [6]. Существующие инструменты управления учётными данными вынуждают пользователя выбирать между удобством облачных решений и безопасностью локальных: ни один из подходов в полной мере не удовлетворяет обоим требованиям одновременно.

В настоящей работе предлагается практическое решение указанного противоречия - кроссплатформенный менеджер паролей PasswordSaver, построенный на архитектуре нулевого разглашения (Zero-Knowledge). Криптографическое ядро системы реализовано на языке Go и включает функцию деривации ключа Argon2id (128 МБ памяти, 3 итерации, 4 потока) и симметричное шифрование AES-256-GCM, обеспечивающее аутентифицированное шифрование с проверкой целостности данных [4, 5]. Серверная часть не располагает ключами дешифрования, что принципиально отличает систему от централизованных облачных решений [9].

В качестве пользовательского интерфейса применяется Telegram-бот, выполняющий одновременно роль фронтенда и встроенного второго фактора аутентификации по Telegram ID. Синхронизация резервных копий реализована по протоколу WebDAV. Для нейтрализации атак визуального перехвата предусмотрен механизм автоматического удаления сообщений с расшифрованными данными по истечении 30-секундного TTL.

Проведён сравнительный анализ PasswordSaver с решениями Bitwarden и KeePass по критериям модели хранения, способа аутентификации и доступа сервера к ключевому материалу. Обозначены перспективные направления развития системы: разработка графического интерфейса, интеграция с платформой ВКонтакте и внедрение модуля напоминаний о ротации паролей.

ABSTRACT

The problem of compromising user credentials remains one of the most acute in modern information security: according to industry reports for 2025-2026, over 80% of successful account hacks are caused by the use of weak or reusable passwords [6]. Existing credential management tools force the user to choose between the convenience of cloud solutions and the security of local ones: neither approach fully satisfies both requirements at the same time.

This paper proposes a practical solution to this contradiction - the cross-platform password manager PasswordSaver, built on a zero-Knowledge architecture. The cryptographic core of the system is implemented in Go and includes the Argon2id key derivation function (128 MB of memory, 3 iterations, 4 streams) and symmetric AES-256-GCM encryption, which provides authenticated encryption with data integrity verification [4,5]. The server side does not have decryption keys, which fundamentally distinguishes the system from centralized cloud solutions [9].

A Telegram bot is used as the user interface, which simultaneously acts as a frontend and a built-in second authentication factor using Telegram ID. Backup code synchronization is implemented using the WebDAV protocol. To neutralize visual interception attacks, a mechanism is provided for automatically deleting messages with decrypted data after a 30-second TTL.

A comparative analysis of PasswordSaver with Bitwarden and KeePass solutions was carried out according to the criteria of the storage model, authentication method, and server access to key material. The promising directions of the system development are outlined: the development of a graphical interface, integration with the platform on the go, and the introduction of a module for reminders about the rotation of pairs.

Ключевые слова: менеджер паролей, кибербезопасность, шифрование, AES-256-GCM, Argon2id, Telegram-бот, Zero-Knowledge, WebDAV.

Keywords: password manager, cybersecurity, encryption, AES-256-GCM, Argon2id, Telegram bot, Zero-Knowledge, WebDAV.

По данным Verizon Data Breach Investigations Report 2024, 68% всех утечек данных обусловлены похищенными или слабыми учётными данными [6]. Годом позже, согласно DBIR 2025, 88% атак на базовые веб-приложения были совершены с использованием скомпрометированных паролей, а в целом 60% всех инцидентов так или иначе затрагивают человеческий фактор [7]. При этом анализ данных похищенного ПО показал: в медианном случае лишь 49% паролей пользователя уникальны - остальные повторяются на разных сервисах [8]. Устойчивость этих показателей от года к году свидетельствует об одном: технические средства защиты без удобных инструментов управления учётными данными работают вхолостую.

Рынок предлагает два принципиально разных подхода. Облачные менеджеры - Bitwarden, 1Password и им подобные - решают проблему синхронизации, но вводят новую: единый централизованный сервер становится привлекательной целью. Локальные решения, прежде всего KeePass, этого недостатка лишены, однако порог входа для рядового пользователя остаётся высоким - настройка синхронизации между несколькими устройствами требует ручной конфигурации. KeePass не имеет официальных приложений для операционных систем, отличных от Windows, а кросс-платформенная синхронизация реализуется исключительно через сторонние плагины. В этом зазоре между удобством и безопасностью и находится ниша для PasswordSaver.

Архитектура системы и криптографическое ядро

Центральным принципом проектирования PasswordSaver является архитектура нулевого разглашения (Zero-Knowledge Architecture). В рамках данной модели шифрование происходит локально - на стороне пользователя. Сервер получает исключительно шифротекст; ключ дешифрования из пользовательской среды не передаётся и серверной частью не генерируется [9]. Это принципиально отличает Zero-Knowledge от систем, декларирующих шифрование, но удерживающих ключ у провайдера: в последнем случае провайдер технически сохраняет возможность расшифровать данные [9]. Применительно к PasswordSaver это означает: даже при полной компрометации сервера злоумышленник получает лишь зашифрованный файл, работа с которым без мастер-ключа криптографически нецелесообразна.

Криптографический стек системы реализован на языке программирования Go. Выбор обусловлен качеством стандартной библиотеки crypto/aes и crypto/rand, нативной поддержкой конкурентных горутин - они задействуются в механизме автоудаления сообщений, описанном ниже, - а также строгой типизацией, снижающей вероятность ошибок при работе с буферами ключевого материала.

Деривация ключа. Для получения 256-битного мастер-ключа из пользовательского пароля применяется функция Argon2id. Алгоритм сочетает в себе свойства вариантов Argon2i и Argon2d: первая половина первого прохода по памяти выполняется с независимым от данных доступом (защита от атак по сторонним каналам), вторая - с зависимым (максимизация стоимости brute-force для атакующего) [4]. Параметры функции в реализации PasswordSaver: 128 МБ оперативной памяти, 3 итерации, 4 параллельных потока. RFC 9106 определяет второй рекомендуемый профиль Argon2id как t=3 при 64 МБ памяти - для ресурсоограниченных сред; выбранный нами профиль с 128 МБ обеспечивает бо́льшие затраты для атакующего при сохранении приемлемого времени отклика на стороне легитимного пользователя [4]. Ключевое преимущество Argon2 перед предшествующими KDF состоит в требовательности к памяти: GPU-ускорение атак резко ограничивается объёмом памяти на ядро, что делает массовый перебор на специализированном железе экономически нецелесообразным [4].

Шифрование хранилища. База данных представляет собой плоскофайловое JSON-хранилище и шифруется алгоритмом AES-256-GCM. Согласно NIST SP 800-38D, режим GCM (Galois/Counter Mode) определяет алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD) и его специализацию GMAC для генерации кодов аутентичности [5]. На практике это означает, что каждая операция шифрования порождает не только шифротекст, но и тег аутентичности; при расшифровке GCM способен обнаружить как случайные искажения данных, так и намеренную их модификацию злоумышленником [5]. Следовательно, подмена или частичная порча зашифрованного файла будет детектирована на этапе расшифровки - без дополнительного уровня верификации целостности на уровне приложения.

Генерация энтропии. Криптографические соли (32 байта) и векторы инициализации (Nonce, 12 байт) формируются посредством CSPRNG операционной системы - вызовом crypto/rand.Read в Go, что исключает предсказуемость nonce и, следовательно, атаки на повторное использование вектора инициализации в рамках одного ключа [5].

Интерфейсный уровень: Telegram как фронтенд и фактор 2FA

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

Отдельного рассмотрения заслуживает защита от атак визуального перехвата (Shoulder Surfing) - сценария, при котором расшифрованный пароль может быть считан посторонним лицом с экрана устройства или из истории переписки. Для нейтрализации этой угрозы реализован механизм Time-To-Live (TTL): после доставки расшифрованного значения в чат сервер запускает асинхронную горутину, которая через 30 секунд удаляет сообщение средствами Telegram Bot API. Пользователю не требуется совершать никаких дополнительных действий; окно экспозиции чувствительных данных ограничено фиксированным интервалом вне зависимости от поведения пользователя.

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

Синхронизация и транспортная безопасность. Резервное копирование и синхронизация хранилища реализованы по протоколу WebDAV с использованием облачного хранилища Яндекс.Диск. Выбор WebDAV обусловлен широкой поддержкой протокола, отсутствием привязки к конкретному провайдеру и возможностью последующей миграции на иные совместимые хранилища (Nextcloud, собственный сервер) без изменения кода клиента.

Взаимодействие между CLI-клиентом и серверной частью защищено по двум независимым рубежам. Первый - транспортное шифрование HTTPS, исключающее перехват и подмену трафика на сетевом уровне. Второй - уникальные API-токены авторизации, генерируемые при первичной регистрации клиента: их компрометация не раскрывает содержимого хранилища, поскольку ключи дешифрования на сервере не хранятся.

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

Сравнительный анализ

Bitwarden также декларирует Zero-Knowledge Encryption как базовую модель безопасности и применяет AES-256 для шифрования данных в хранилище. Однако принципиальное различие между Bitwarden и PasswordSaver лежит не в криптографии, а в архитектурной зависимости: Bitwarden в облачном режиме предполагает централизованный сервер, который становится единой точкой отказа и привлекательной целью для атак. Self-hosted развёртывание Bitwarden снимает эту проблему, однако требует поддержки полноценной серверной инфраструктуры. PasswordSaver спроектирован изначально с расчётом на то, что сервер потенциально скомпрометирован.

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

Заключение

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

Криптографическая обоснованность. Применение связки Argon2id + AES-256-GCM обеспечивает двухуровневую защиту хранилища: вычислительная трудоёмкость деривации ключа делает атаки полным перебором экономически нецелесообразными [4], тогда как аутентифицированный режим шифрования гарантирует обнаружение любой несанкционированной модификации шифротекста при расшифровке. Оба алгоритма стандартизированы - Argon2id закреплён в RFC 9106 (IRTF, 2021), AES-GCM в NIST SP 800-38D, - что обеспечивает воспроизводимость и аудитируемость принятых криптографических решений [4, 5].

Соответствие требованиям регуляторов. Реализованная архитектура согласуется с российской нормативной базой в области защиты информации. Приказ ФСТЭК России №21 в рамках меры ИАФ.4 предписывает защиту аутентификационной информации от несанкционированного доступа и модификации, обновление аутентификационных данных с периодичностью, установленной оператором, а также блокирование и замену скомпрометированных средств аутентификации [1]. PasswordSaver выполняет эти требования на архитектурном уровне: мастер-ключ не хранится на сервере, хранилище защищено AEAD-шифрованием, а компрометация серверной части не раскрывает аутентификационных данных пользователей. Смежные требования содержатся в ГОСТ Р ИСО/МЭК 27002 (раздел 9.3, управление паролями пользователей) [2] и ГОСТ Р 57580.1-2017 - для организаций финансового сектора [3].

Архитектурная эффективность Zero-Knowledge. Принцип нулевого разглашения радикально сужает поверхность атаки: при компрометации серверной части злоумышленник получает лишь зашифрованный blob без каких-либо возможностей его расшифровки. Это выгодно отличает PasswordSaver от централизованных облачных решений, при взломе которых зашифрованные данные всех пользователей оказываются у атакующего одновременно.

Практическая применимость. Использование Telegram одновременно в роли фронтенда и второго фактора аутентификации снижает порог входа: не требуется устанавливать отдельное мобильное приложение или настраивать TOTP-токены. Механизм TTL-удаления сообщений нейтрализует угрозу визуального перехвата без каких-либо действий со стороны пользователя.

Перспективы развития определены по трём направлениям.

Первое - графический интерфейс (GUI) для Windows на базе Fyne или Wails. Это приблизит PasswordSaver по удобству к коммерческим аналогам и расширит аудиторию за счёт пользователей, для которых CLI представляет избыточный порог входа.

Второе - интеграция с платформой ВКонтакте через VK Mini Apps Bot API. Реализация второго независимого канала доступа устраняет единую точку отказа на уровне интерфейса и повышает отказоустойчивость системы в целом.

Третье - модуль мониторинга состояния учётных данных. В соответствии с практикой, сложившейся в российской отрасли ИБ, для сервисных учётных записей рекомендуется смена паролей не реже одного раза в 180 дней. На этой основе планируется реализовать проактивное оповещение пользователя о «возрасте» каждой записи, а также интеграцию с открытыми базами утечек - например, через API Have I Been Pwned, - чтобы уведомление поступало не по расписанию, а при фактическом появлении учётных данных в скомпрометированных дампах. Такой подход соответствует мере ИАФ.4 Приказа ФСТЭК №21 в части своевременной замены скомпрометированных средств аутентификации.

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

Список литературы:

1. ГОСТ Р ИСО/МЭК 27002-2021. Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности. — М.: Стандартинформ, 2021. — URL: https://docs.cntd.ru/document/1200179669 (дата обращения 10.05.2026)
2. ГОСТ Р ИСО/МЭК 27001-2021. Информационные технологии. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования. — М.: Стандартинформ, 2021. — URL: https://docs.cntd.ru/document/1200181890 (дата обращения 10.05.2026)
3. Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». — URL: https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21 (дата обращения 10.05.2026)
4. Biryukov A., Dinu D., Khovratovich D., Josefsson S. Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications: RFC 9106 / Internet Research Task Force (IRTF). — 2021. — URL: https://datatracker.ietf.org/doc/rfc9106/ (дата обращения 10.05.2026)
5. Dworkin M. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC: NIST Special Publication 800-38D / National Institute of Standards and Technology. — 2007. — URL: https://csrc.nist.gov/pubs/sp/800/38/d/final (дата обращения 10.05.2026)
6. Verizon. 2024 Data Breach Investigations Report. — Verizon Business, 2024. — URL: https://www.verizon.com/business/resources/reports/dbir/ (дата обращения 10.05.2026)
7. Verizon. 2025 Data Breach Investigations Report. — Verizon Business, 2025. — URL: https://www.verizon.com/business/resources/reports/dbir/ (дата обращения 10.05.2026)
8. Verizon. Credential Stuffing Attacks: 2025 DBIR Research. — Verizon Business, 2025. — URL: https://www.verizon.com/business/resources/articles/credential-stuffing-attacks-2025-dbir-research/ (дата обращения 10.05.2026)
9. Bitwarden. Zero-Knowledge Encryption: White Paper. — 2024. — URL: https://bitwarden.com/resources/zero-knowledge-encryption-white-paper/ (дата обращения 10.05.2026)