MeldID добавил режим паники: что происходит, когда доступу к аккаунту больше нельзя доверять
В MeldID появились новые механизмы защиты для нестандартных ситуаций: отложенная смена пароля, автоматическое завершение восстановления без мобильного приложения и режим паники, который отзывает активные доступы, блокирует незавершённые попытки смены пароля и при этом не удаляет сохранённые данные пользователя.
В предыдущей статье о MeldID я писал о том, как система работает в обычном режиме: хранит управляемый профиль, помогает входить в подключённые сервисы, синхронизирует TOTP-записи между устройствами и позволяет подтверждать новые авторизации через мобильное приложение.
Но у любой системы идентификации есть сценарий, о котором обычно вспоминают слишком поздно: что делать, если пользователь больше не доверяет текущему состоянию доступа к своему аккаунту?
Для этого не обязательно уже знать, что произошёл взлом. Иногда достаточно неожиданного письма о восстановлении пароля, неизвестной сессии или входа с устройства, которого владелец не узнаёт.
Именно для таких ситуаций в MeldID появились два новых механизма: отложенная смена пароля и режим паники.
Сначала важно понять, как устроен пароль MeldID
В MeldID пользователь не придумывает пароль самостоятельно — его генерирует система. Это позволяет сразу исключить слабые и предсказуемые комбинации, повторное использование привычного пароля и другие проблемы, связанные с самостоятельным выбором.
При этом действующий пароль не отправляется пользователю по электронной почте. Почтовый ящик не является местом, из которого можно получить существующий пароль MeldID.
Процедура восстановления тоже не раскрывает старый пароль. Она позволяет запустить создание нового.
Поэтому компрометация электронной почты создаёт другую угрозу: человек, получивший доступ к почтовому ящику, не узнаёт действующий пароль MeldID, но может попытаться воспользоваться процедурой восстановления и установить новый.
Именно этот сценарий стал одной из причин изменить саму логику восстановления.
Пароль теперь не меняется мгновенно
В привычном сценарии восстановления всё происходит почти сразу. Пользователь запрашивает новый пароль, получает письмо и завершает процедуру.
Это удобно, пока электронная почта находится только под контролем владельца. Но если доступ к ней получил кто-то другой, мгновенное восстановление превращает почтовый ящик в прямой путь к захвату связанной с ним учётной записи.
В MeldID запрос на новый пароль сначала становится предупреждением, а не немедленной заменой старого. Пользователь получает уведомление о попытке восстановления, после чего начинается установленный период ожидания.
Продолжительность этого периода может изменяться, но принцип остаётся тем же: между запросом и фактической активацией нового пароля появляется время для проверки ситуации.
Старый пароль в этот момент сохраняет свою силу. Поэтому сам факт запуска восстановления ещё не означает, что контроль над аккаунтом перешёл к другому человеку.
Если приложение недоступно
Есть важный сценарий, который легко упустить. Пользователь может сам восстанавливать пароль, но при этом не иметь доступа к приложению MeldID: телефон потерян, сломан, разряжен или временно недоступен.
В этом случае восстановление всё равно сможет завершиться. После окончания установленного периода новый пароль автоматически вступит в силу. Мобильное приложение не является обязательным условием для стандартной процедуры восстановления.
Поэтому человеку, который сам запустил смену пароля и сейчас не может открыть приложение, не нужно начинать процедуру заново. Достаточно дождаться её завершения и войти с новым паролем.
Если приложение доступно, возможностей больше: пользователь может немедленно активировать новый пароль или отменить подозрительный запрос. Если доступа к приложению нет, продолжает работать стандартное отложенное восстановление.
Пользователь сам решает, что делать дальше
Если восстановление действительно запускал владелец аккаунта и приложение находится под рукой, он может открыть MeldID и активировать новый пароль сразу, не дожидаясь окончания установленного периода.
Если запрос оказался неожиданным, его можно отменить из приложения. Новый пароль в этом случае не становится действующим, а прежний сохраняется.
Для меня это важное изменение самой логики восстановления. Система не считает любой запрос автоматически правильным только потому, что он был запущен через электронную почту. Она оставляет владельцу аккаунта возможность вмешаться и принять решение через доверенное мобильное устройство.
Представим обычную ситуацию: человек получает уведомление о смене пароля, хотя сам ничего не запрашивал. Он отменяет операцию в приложении, после чего уже разбирается с электронной почтой, проверяет устройства и ищет причину подозрительной активности.
MeldID не может восстановить контроль над скомпрометированным почтовым ящиком. Но он может не позволить компрометации почты немедленно привести к установке нового пароля основной учётной записи.
Режим паники отзывает активные доступы
Отложенная смена пароля помогает выиграть время. Режим паники предназначен для ситуации, когда этого уже недостаточно и пользователь хочет немедленно прекратить действие ранее выданных доступов к аккаунту.
Он запускается из мобильного приложения одним действием.
После активации система отзывает действующие токены — ключи доступа, по которым приложения и сайты определяют, что пользователь уже авторизован. Одновременно прекращается действие существующих сессий на мобильных клиентах и веб-сайтах, связанных с этим аккаунтом.
Это означает, что прекращается не только текущая сессия на телефоне. Авторизация отзывается и на других смартфонах, планшетах, браузерах и подключённых приложениях, где ранее был выполнен вход.
Режим действует в течение установленного периода. Его продолжительность может меняться, поэтому важен не конкретный срок, а сам принцип: существующие доступы прекращаются, а пользователь получает защищённое время для проверки ситуации.
Паника не удаляет данные
Название режима может звучать радикально, поэтому здесь важно отдельно объяснить, чего он не делает.
Режим паники не стирает TOTP-записи, сохранённый профиль, настройки или другие данные пользователя. Он не очищает содержимое аккаунта и не превращает его в пустой.
Меняется состояние доступа: действующие токены отзываются, а открытые сессии прекращаются. После возвращения аккаунта в нормальный режим сохранённые данные остаются на месте и не требуют повторного добавления.
Это принципиальная разница между аварийным прекращением доступа и уничтожением содержимого аккаунта. Пользователь может закрыть существующие подключения, не опасаясь, что вместе с ними исчезнут его записи или настройки.
Что происходит со сменой пароля во время паники
У режима паники есть ещё одно важное правило: он прекращает все незавершённые попытки смены пароля.
Не имеет значения, когда был запрошен новый пароль — до включения режима паники или уже во время его действия. Такой запрос не сможет автоматически завершиться после выхода из защитного режима.
После окончания паники действующим остаётся пароль, который был установлен до её активации.
Это сделано намеренно.
Обычная процедура восстановления рассчитана на то, что владелец аккаунта может увидеть подозрительный запрос в приложении MeldID и отменить его до того, как новый пароль вступит в силу.
Во время паники полагаться на этот сценарий уже нельзя.
Представим, что пользователь заметил подозрительную активность и включил защитный режим. Если при этом позволить обычному таймеру восстановления продолжать работать, злоумышленник сможет запросить новый пароль во время паники. Если период ожидания закончится раньше самого защитного режима, новый пароль успеет вступить в силу ещё до возвращения аккаунта в нормальное состояние.
Получился бы парадокс: пользователь включил усиленную защиту, но именно в этот период система позволила изменить пароль, не дав владельцу воспользоваться обычным механизмом отмены через приложение.
Поэтому паника не ставит восстановление на паузу, чтобы продолжить его позже. Она обрывает незавершённую процедуру.
Запросы, существовавшие до включения паники, не смогут изменить пароль после её окончания. То же относится к запросам, появившимся уже во время действия защитного режима.
Таким образом, ничего из незавершённого восстановления не переносится через границу паники.
А если пользователь сам хочет сначала изменить пароль
Режим паники не ограничивает владельца в выборе последовательности действий.
Если доступ к приложению MeldID находится у пользователя и он считает, что пароль тоже необходимо заменить, он может сначала запустить смену пароля и сразу подтвердить новый пароль через приложение.
В этом случае смена завершается до включения паники.
После этого пользователь запускает защитный режим уже с новым действующим паролем. Именно этот пароль сохранится после окончания паники.
Есть и другой вариант: сначала включить панику, разобраться с причиной подозрительной активности, а после её окончания при необходимости запустить новую процедуру смены пароля.
Смысл механизма не в том, чтобы заставить пользователя действовать только в одной последовательности. Главное правило другое: незавершённая смена пароля не должна пережить режим паники.
Паника даёт время вернуть контроль над почтой
Есть сценарий, для которого этот механизм особенно важен: пользователь считает, что проблема находится не в MeldID и не в его телефоне, а в электронной почте.
Именно почта используется как один из каналов восстановления. Поэтому её компрометация опасна даже тогда, когда действующий пароль MeldID остаётся неизвестен постороннему.
В такой ситуации пользователь может включить режим паники и заняться непосредственно источником проблемы: восстановить доступ к почтовому аккаунту, изменить его пароль, завершить неизвестные почтовые сессии и проверить настройки безопасности.
На время действия паники MeldID не позволяет процедуре восстановления создать новый действующий пароль.
Если кто-то уже успел запросить восстановление до включения паники, эта попытка не переживёт защитный режим. Если новый запрос появится во время паники, результат будет тем же.
Получается защищённое временное окно: активные доступы MeldID уже отозваны, потенциально скомпрометированная электронная почта не может быть использована для подготовки нового пароля к моменту окончания паники, а у владельца есть время вернуть контроль над самим почтовым ящиком.
После окончания защитного режима действующим остаётся прежний пароль MeldID. Если контроль над электронной почтой восстановлен и других признаков проблемы нет, пользователь может снова пользоваться аккаунтом в обычном режиме.
Если после проверки он решит изменить и пароль MeldID, это можно сделать отдельно.
Причин включить панику может быть много
Для запуска режима не требуется сначала доказать факт взлома.
Телефон мог попасть в чужие руки. В списке устройств могла появиться неизвестная сессия. Пользователь мог получить неожиданное уведомление о входе или восстановлении. Иногда подозрение возникает не из-за одного явного события, а из совокупности небольших признаков.
В таких обстоятельствах человеку не всегда нужно проводить расследование перед первым защитным действием. Иногда разумнее сначала временно отозвать активные доступы, а затем проверять подробности.
Здесь MeldID исходит из простой логики: если владелец аккаунта считает ситуацию опасной и у него есть доступ к доверенному приложению, он должен иметь возможность немедленно запустить защитный сценарий. Система не требует сначала доказать факт атаки.
Почему одной смены пароля бывает недостаточно
Пароль — только один из элементов авторизации. Если где-то уже существует действующая сессия или был выдан токен доступа, изменение одного пароля само по себе не является тем же самым действием, что отзыв всех ранее выданных доступов.
Именно поэтому режим паники работает шире. Он не просто меняет один параметр учётной записи, а переводит весь аккаунт в отдельное защитное состояние.
Последовательность получается такой:
активные сессии и токены отзываются;
незавершённые попытки смены пароля, начатые до паники, прекращаются;
запросы на восстановление, сделанные во время паники, не смогут изменить пароль после её окончания;
действующим остаётся пароль, с которым аккаунт вошёл в режим паники;
пользователь получает время проверить почту, устройства и другие возможные источники проблемы;
после выхода из защитного режима он возвращается к обычной работе или при необходимости отдельно меняет пароль.
Это не замена обычным механизмам безопасности, а отдельный аварийный сценарий для ситуации, когда доверие к текущему состоянию доступа временно потеряно.
Мобильное приложение как доверенная точка
Новые функции доступны в приложениях MeldID для iPhone и Android. В этой архитектуре телефон становится не просто ещё одним устройством для входа, а доверенной точкой управления безопасностью аккаунта.
Через приложение можно:
подтвердить отложенную смену пароля;
отменить подозрительный запрос;
включить режим паники;
прекратить действие активных сессий на разных устройствах;
определить, что должно происходить с аккаунтом дальше.
При этом мобильное приложение не отменяет TOTP и не заменяет другие способы защиты. Оно добавляет отдельный канал управления для ситуаций, когда обычной авторизации уже недостаточно для уверенности в состоянии аккаунта.
Где проходит граница защиты MeldID
Важно разделять безопасность самого механизма MeldID и безопасность среды, в которой им пользуются.
MeldID устроен так, чтобы сам сервис не создавал штатного канала для получения действующего пароля. Пароль генерируется системой, не выбирается пользователем и не передаётся по электронной почте. Восстановление также не раскрывает существующий пароль, а запускает процедуру создания нового.
Но пользователь по-прежнему может самостоятельно раскрыть свои учётные данные, например передав их другому человеку или введя там, где этого делать не следовало.
Отдельный уровень — безопасность самого устройства и его операционной системы. Мобильное приложение работает внутри механизмов защиты, предоставляемых iOS и Android, и не может подменить собой безопасность самой платформы.
Поэтому MeldID концентрируется на тех рисках, которыми может управлять на своей стороне: генерации учётных данных, авторизации, токенах, сессиях, восстановлении и реакции на потенциальную компрометацию канала восстановления.
От входа к реагированию
Когда я впервые знакомился с MeldID, его можно было описать как систему единой идентификации и управления профилем. После выпуска мобильных приложений и появления новых защитных механизмов это описание стало слишком узким.
Теперь система отвечает не только на вопрос «как войти?», но и на более сложные вопросы:
что делать при неожиданной попытке восстановления;
как восстановить аккаунт без доступа к приложению;
как получить время на проверку перед активацией нового пароля;
как отменить восстановление, запущенное не владельцем;
как отозвать активные сессии;
как не позволить скомпрометированной почте изменить пароль во время аварийного режима;
как вернуть контроль над внешним каналом восстановления;
как сохранить пользовательские данные при прекращении всех активных доступов;
как вернуться к нормальной работе после проверки ситуации.
В итоге получается последовательная модель защиты.
Действующий пароль MeldID не передаётся через канал восстановления. Получение доступа к электронной почте само по себе не раскрывает его, но может позволить запустить процедуру создания нового пароля. Поэтому восстановление выполняется с задержкой и может быть отменено через доверенное приложение.
Если и этого недостаточно, режим паники разрывает активные сессии, отзывает токены и не позволяет незавершённому восстановлению пережить защитный период.
Пользователь получает то, что особенно важно при реальном инциденте: время.
Время вернуть контроль над электронной почтой, проверить устройства, разобраться в произошедшем и только после этого снова открыть нормальный доступ к аккаунту.
Именно поэтому режим паники в MeldID — это не просто кнопка «выйти везде». Это отдельный сценарий реагирования на ситуацию, когда обычной авторизации уже недостаточно и сначала необходимо восстановить доверие к окружению аккаунта.
Подробнее о проекте: meldid.de .