MeldID додав режим паніки: що трапиться, коли доступ до акаунту більше не можна довіряти

У попередній статті про MeldID я писав про те, як система працює у звичайному режимі: зберігає керований профіль, допомагає входити у підключені сервіси, синхронізує запис TOTP між пристроями та дозволяє підтверджувати нові авторизації через мобільний додаток.

Але у будь-якої системи ідентифікації є сценарій, про який зазвичай згадують надто пізно: що робити, якщо користувач більше не довіряє поточному стану доступу до свого акаунту?

Для цього не обов’язково вже знати, що стався злом. Інколи достатньо несподіваного листа про відновлення паролю, невідомої сесії або входу з пристрою, який власник не впізнає.

Саме для таких ситуацій у MeldID з'явилися два нові механізми: відкладена зміна паролю та режим паніки.

Спершу важливо зрозуміти, як устроєний пароль MeldID

У MeldID користувач не придумує пароль самостійно — його генерує система. Це дозволяє одразу виключити слабкі й передбачувані комбінації, повторне використання звичної паролі та інші проблеми, пов’язані з самостійним вибором.

При цьому дійсний пароль не відправляється користувачу електронною поштою. Ящик не є місцем, з якого можна отримати існуючий пароль MeldID.

Процедура відновлення також не розкриває старий пароль. Вона дозволяє запустити створення нового.

Тому компрометація електронної пошти створює іншу загрозу: особа, яка отримала доступ до поштового ящика, не дізнається поточний пароль MeldID, але може спробувати скористатися процедурою відновлення й встановити новий.

Саме цей сценарій став однією з причин змінити логіку відновлення.

Пароль тепер не змінюється миттєво

У звичайному сценарії відновлення все відбувається майже одразу. Користувач запитує новий пароль, отримує лист і завершує процес.

Це зручно, поки доступ до пошти є під контролем власника. Але якщо доступ отримала інша особа, миттєве відновлення перетворює поштову скриньку на прямий шлях до захоплення пов’язаного акаунту.

У MeldID запит на новий пароль спершу стає попередженням, а не негайною заміною старого. Користувач отримує повідомлення про спробу відновлення, після чого починається встановлений період очікування.

Тривалість цього періоду може змінюватися, але принцип залишається тим самим: між запитом і фактичною активацією нового пароля проходить час для перевірки ситуації.

Старий пароль у цей момент зберігає свою силу. Тому сам факт ініціації відновлення ще не означає, що контроль над акаунтом перейшов до іншої особи.

Якщо додаток недоступне

Є важливий сценарій, який легко пропустити. Користувач може сам відновлювати пароль, але при цьому не мати доступу до додатку MeldID: телефон втраченого, зламаний, розряджений або тимчасово недоступний.

У цьому випадку відновлення все одно зможе завершитися. Після закінчення встановленого періоду новий пароль автоматично набирає чинності. Мобільний додаток не є обов’язковою умовою для стандартної процедури відновлення.

Тому людині, яка сама ініціювала зміну паролю й наразі не може відкрити додаток, не потрібно починати процес заново. Достатньо почекати його завершення і увійти з новим паролем.

Якщо додаток доступний, можливості ширші: користувач може негайно активувати новий пароль або скасувати підозрілий запит. Якщо доступу до додатку нема, продовжує діяти стандартне відкладене відновлення.

Користувач сам приймає рішення, що робити далі

Якщо відновлення справді ініціював власник акаунту і додаток під рукою, він може відкрити MeldID і активувати новий пароль одразу, не чекаючи закінчення встановленого періоду.

Якщо запит став несподіванкою, його можна скасувати з додатку. Новий пароль у цьому випадку не стає дійсним, а попередній залишається активним.

Для мене це важлива зміна логіки відновлення. Система не вважає будь-який запит автоматично правильним просто тому, що він був запущений через електронну пошту. Вона дає власнику акаунту можливість втрутитися й прийняти рішення через довірений мобільний пристрій.

Уявімо звичайну ситуацію: людина отримує сповіщення про зміну паролю, хоча сама нічого не запитувала. Вона скасовує операцію у додатку, після чого розбирається з поштою, перевіряє пристрої і шукає причину підозрілої активності.

MeldID не може відновити контроль над скомпрометованим поштовим ящиком. Але може не допустити, щоб компрометація пошти негайно призвела до встановлення нового паролю основного акаунту.

Режим паніки відкликає активні доступи

Відкладене змінення паролю допомагає виграти час. Режим паніки призначений для ситуації, коли цього вже недостатньо і користувач хоче негайно припинити дії раніше виданих доступів до акаунту.

Він запускається з мобільного додатку одним дівиом.

Після активації система відкликає дійсні токени — ключі доступу, за допомогою яких додатки і сайти визначають, що користувач вже авторизований. Одночасно припиняється дія існуючих сесій на мобільних клієнтах і веб-сайтах, пов’язаних із цим акаунтом.

Це означає, що припиняється не лише поточна сесія на телефоні. Авторизація відкликається і на інших смартфонах, планшетах, браузерах і підключених додатках, де раніше було виконано вхід.

Режим діє протягом встановленого періоду. Його тривалість може змінюватися, тому важлива не конкретна дата, а сам принцип: існуючі доступи припиняються, а користувач отримує захищений час для перевірки ситуації.

Паніка не видаляє дані

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

Режим паніки не стирає TOTP-записи, збережений профіль, налаштування чи інші дані користувача. Він не очищає вміст акаунту і не робить його порожнім.

Змінюється стан доступу: дійсні токени відкликаються, а відкриті сесії припиняються. Після повернення акаунта у нормальний режим збережені дані залишаються на місці і не потребують повторного додавання.

Це принципова різниця між аварійним припиненням доступу і знищенням вмісту акаунту. Користувач може закрити існуючі підключення, не боячись, що разом із ними зникнуть його записи або налаштування.

Що відбувається з зміною паролю під час паніки

У режимі паніки є ще одне важливе правило: він припиняє всі незакінчені спроби зміни паролю.

Не має значення, коли був запит на новий пароль — до активації режиму паніки або вже під час його дії. Такий запит не зможе автоматично завершитися після виходу з режиму захисту.

Після закінчення паніки дійним залишається пароль, який був встановлений перед її активізацією.

Це зроблено навмисне.

Звичайна процедура відновлення передбачає, що власник акаунту може побачити підозрілі запити у MeldID і скасувати їх до того, як новий пароль набере чинності.

Під час паніки на цей сценарій уже покладатися не можна.

Уявімо, що користувач помітив підозрілу активність і включив захисний режим. Якщо при цьому дозволити стандартний таймер відновлення працювати далі, зловмисник зможе запитати новий пароль під час паніки. Якщо період очікування закінчиться раніше за сам режим паніки, новий пароль встигне вступити в силу ще до повернення акаунту у нормальний стан.

Виник би парадокс: користувач увімкнув посилений захист, а саме в цей період система дозволила змінити пароль, не давши власнику скористатися звичайним механізмом скасування через додаток.

Тому паніка не призупиняє відновлення, щоб продовжити його пізніше. Вона перериває незакінчену процедуру.

Запити, зроблені до включення паніки, не зможуть змінити пароль після її завершення. Те саме стосується запитів, з’явлених вже під час дії режиму захисту.

Таким чином, нічого з незавершеного відновлення не переноситься через межу паніки.

А якщо користувач сам хоче спершу змінити пароль

Режим паніки не обмежує власника у виборі послідовності дій.

Якщо доступ до додатку MeldID є у користувача і він вважає, що пароль також потрібно замінити, він може спочатку запустити зміну паролю й одразу підтвердити новий пароль через додаток.

У цьому випадку зміна завершується до включення паніки.

Після цього користувач активує захисний режим уже з новим дійсним паролем. Саме цей пароль зберігається після завершення паніки.

Інший варіант — спочатку включити паніку, розібратися з причиною підозрілої активності, а після її завершення, за потреби, розпочати нову процедуру зміни паролю.

Суть механізму не у тому, щоб змусити користувача діяти лише у визначеній послідовності. Головне правило інше: незакінчена зміна паролю не повинна пережити режим паніки.

Паніка дає час повернути контроль над поштою

Існує сценарій, для якого цей механізм особливо важливий: користувач вважає, що проблема не у MeldID і не у його телефоні, а у електронній пошті.

Саме пошта використовується як один із каналів відновлення. Тому її компрометація небезпечна навіть тоді, коли дійсний пароль MeldID залишається невідомим сторонньому.

У такій ситуації користувач може увімкнути режим паніки і зайнятися безпосередньо джерелом проблеми: відновити доступ до поштового акаунту, змінити його пароль, завершити невідомі поштові сесії й перевірити налаштування безпеки.

На час дії режиму паніки MeldID не дозволяє процедуру відновлення створити новий дійсний пароль.

Якщо хтось уже встиг запитати відновлення до активації паніки, ця спроба не переживе режим захисту. Якщо новий запит з’явиться під час дії режиму, результат буде таким самим.

Отже, утворюється захищене тимчасове вікно: активні доступи MeldID уже відкликані, потенційно скомпрометований поштовий ящик не може бути використаний для підготовки нового пароля до моменту закінчення паніки, а власник має час повернути контроль над самим поштовим ящиком.

Після завершення режиму паніки дійсним залишається попередній пароль MeldID. Якщо контроль над поштою відновлено і інших ознак проблем немає, користувач може знову користуватися акаунтом у звичайному режимі.

Якщо після перевірки він ухвалить змінити і пароль MeldID, це можна зробити окремо.

Мотиви для запуску паніки можуть бути різні

Для запуску режиму не потрібно спершу доводити факт зламу.

Телефон міг потрапити до чужих рук. У списку пристроїв могла з’явитися невідома сесія. Користувач міг отримати несподіване повідомлення про вхід або відновлення. Інколи підозра виникає не через одне явне подію, а з сукупності дрібних ознак.

У таких випадках не завжди потрібно проводити розслідування перед першим захисним кроком. Іноді розумніше спершу тимчасово відкликати активні доступи, а потім перевіряти деталі.

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

Чому однієї зміни паролю недостатньо

Пароль — лише один з елементів авторизації. Якщо вже існує дійсна сесія або був виданий токен доступу, зміна одного паролю сама по собі не є тим самим, що й відкликання всіх раніше виданих доступів.

Саме тому режим паніки працює ширше. Він не просто змінює один параметр акаунту, а переводить весь акаунт у окремий захисний стан.

Послідовність виглядає так:

1. активні сесії та токени відкликаються;

2. незакінчені спроби зміни паролю, початі до паніки, припиняються;

3. запити на відновлення, зроблені під час паніки, не зможуть змінити пароль після її завершення;

4. поточним залишається пароль, з яким акаунт увійшов у режим паніки;

5. користувач отримує час перевірити поштову скриньку, пристрої та інші можливі джерела проблем;

6. після виходу з захисного режиму він повертається до звичайної роботи або за потреби окремо змінює пароль.

Це не заміна стандартних механізмів безпеки, а окремий аварійний сценарій для ситуації, коли довіра до поточного стану доступу тимчасово втрачена.

Мобільний додаток як довірена точка

Нові функції доступні у додатках MeldID для iPhone та Android. У цій архітектурі телефон стає не просто ще одним пристроєм для входу, а довіреною точкою управління безпекою акаунту.

За допомогою додатку можна:

• підтвердити відкладену зміну паролю;

• скасувати підозрілий запит;

• увімкнути режим паніки;

• припинити дію активних сесій на різних пристроях;

• визначити, що має відбуватися з акаунтом далі.

При цьому мобільний додаток не скасовує TOTP і не замінює інші способи захисту. Він додає окремий канал управління для ситуацій, коли звичайна авторизація вже недостатня для впевненості у стані акаунту.

Де проходить межа захисту MeldID

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

MeldID налаштований так, щоб сам сервіс не створював штатного каналу для одержання дійсного паролю. Пароль генерується системою, не вибирається користувачем і не передається поштою. Відновлення також не розкриває існуючий пароль, а запускає процедуру створення нового.

Але користувач все одно може самостійно розкрити свої облікові дані, наприклад, передавши їх іншим або ввівши у неналежне місце.

Особливий рівень — безпека самого пристрою і його операційної системи. Мобільний додаток працює у рамках захисних механізмів iOS та Android і не може замінити безпеку самої платформи.

Тому MeldID зосереджений на тих ризиках, якими може керувати на стороні: генерації даних, авторизації, токенах, сесіях, відновленні і реагуванні на потенційну компрометацію каналу відновлення.

Від входу до реагування

Коли я вперше знайомився з MeldID, його можна було описати як систему єдиної ідентифікації і управління профілем. Після запуску мобільних додатків і появи нових механізмів захисту це опис стало надто вузьким.

Зараз система відповідає не лише на питання «як увійти?», але й на більш складні запитання:

• що робити при несподіваній спробі відновлення;

• як відновити акаунт без доступу до додатку;

• як отримати час для перевірки перед активацією нового паролю;

• як скасувати відновлення, запущене не власником;

• як відкликати активні сесії;

• як не дозволити скомпрометованій пошті змінити пароль під час аварійного режиму;

• як повернути контроль над зовнішнім каналом відновлення;

• як зберегти користувацькі дані після припинення всіх активних доступів;

• як повернутися до нормальної роботи після перевірки ситуації.

В підсумку формується послідовна модель захисту.

Дійсний пароль MeldID не передається через канал відновлення. Одержання доступу до пошти саме по собі не розкриває його, але може дозволити запустити процедуру створення нового паролю. Тому відновлення здійснюється із затримкою й може бути скасоване через довірений додаток.

Якщо і цього недостатньо, режим паніки розриває активні сесії, відкликає токени і не дозволяє незавершеному відновленню пережити захисний період.

Користувач отримує саме те, що особливо важливо під час реального інциденту: час.

Час повернути контроль над поштою, перевірити пристрої, розібратись у ситуації і вже потім відновити нормальний доступ до аккаунту.

Саме тому режим паніки у MeldID — це не просто кнопка «вийти з усіх пристроїв». Це окремий сценарій реагування на ситуацію, коли звичайна авторизація вже недостатня і спершу потрібно відновити довіру до оточення акаунту.

Детальніше про проект: meldid.de.