MeldID: от единого аккаунта к системе управления цифровым доступом

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

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

Следующим шагом стали приложения для iPhone и Android. И здесь особенно интересно не само появление мобильного клиента, а то, какие задачи в нём удалось объединить.

Обычный TOTP — с другой задачей

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

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

Большинство аутентификаторов отвечают на вопрос: «Как показать шестизначный код?» Здесь решается более широкая задача: как безопасно управлять жизненным циклом TOTP-секретов — от добавления и хранения до восстановления на другом устройстве и удаления записи.

Офлайн-режим работает полноценно

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

Уже сохранённые записи продолжают работать без интернета. Коды создаются непосредственно на телефоне, поэтому временное отсутствие связи не мешает пройти двухфакторную проверку.

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

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

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

Новый телефон не означает новый набор кодов

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

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

Не имеет значения, был ли предыдущий аппарат на Android, а новый — iPhone, или наоборот. Можно подключить второй, третий и последующие телефоны, не создавая отдельный процесс переноса для каждой платформы.

Представим, что смартфон неожиданно сломался во время поездки. Вместо восстановления доступа отдельно в каждом сервисе пользователь входит в MeldID на новом устройстве и завершает настройку хранилища. После этого его TOTP-записи возвращаются в приложение.

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

Что хранится на сервере

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

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

Поэтому утечка одной базы не превращается в готовый список секретов для генерации кодов. Злоумышленник получает зашифрованные блоки, а не открытые TOTP-данные.

Здесь важно не давать абсолютных обещаний. Точнее сказать так: открытые TOTP-секреты в базе не хранятся, а одной копии базы недостаточно для их использования.

Подтверждение входа через MeldID

Вторая важная функция приложения — Login Approval, то есть отдельное подтверждение авторизации.

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

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

В отличие от обычного push-подтверждения, Login Approval встроен непосредственно в архитектуру MeldID и может использоваться всеми сервисами, подключёнными к этой системе идентификации.

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

TOTP и Login Approval дополняют друг друга

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

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

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

Что изменилось в самом MeldID

Когда я впервые знакомился с проектом, его основной идеей казалось управление единой учётной записью и переносимым профилем. Теперь стало заметно, что MeldID постепенно превращается в личный центр управления цифровым доступом.

Здесь можно:

• получать TOTP-коды без интернета;

• добавлять новые записи офлайн;

• автоматически восстанавливать их на новом устройстве;

• использовать несколько телефонов;

• разделять несколько аккаунтов на одном устройстве;

• подтверждать или отклонять новые входы.

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

Безопасность здесь строится не на одном механизме, а на совокупности решений: TOTP-секреты не хранятся в открытом виде, доступ не привязывается навсегда к одному телефону, разные аккаунты остаются изолированными друг от друга, а вход в поддерживаемые сервисы завершается только после подтверждения с доверенного устройства.