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-секрети не зберігаються у відкритому вигляді, доступ не прив’язаний назавжди до одного телефону, різні облікові записи залишаються ізольованими один від одного, а входи у підтримувані сервіси завершуються лише після підтвердження з довіреного пристрою.