Хороший интерфейс должен помогать пользователю. А что, если я скажу, что иногда хороший интерфейс должен ему мешать?
Звучит странно, но иногда проектировать цифровые продукты, которые раздражают, сбивают с толку и противоречат логике, — это не баг, а фича. Особенно если речь идёт о защите богатства, конфиденциальных данных и секретов, которые стоят сотни миллионов долларов.
Последние несколько лет я проектирую стартап-инкубаторы и цифровые сейфы (что-то типа Leafplanner, но для индивидуального пользования) для HNWI/UHNWI (человеческим языком – для состоятельных людей), и это дало уникальный опыт, особенно в части организации безопасности: иногда лучший способ защитить дверь — это спрятать её там, где никто даже не подумает её искать.
И сегодня я расскажу, почему «User-Hostile дизайн» может стать вашим лучшим другом в вопросе безопасности.
Основной принцип проектирования виртуальных сейфов
Задача не просто защитить данные, а создать систему, где правильные люди получают доступ в нужный момент, а посторонние — никогда.
Представьте виртуальный сейф — цифровое хранилище данных, содержащее информацию об активах (чем владеешь, как владеешь, документы, бенефициары и т.д.) на сотни миллионов долларов. Типичная аудитория таких решений — состоятельные люди, привыкшие держать всё под личным контролем. Доступ к подобной информации – достаточно чувствительная тема и наши уважаемые хайнеты весьма резонно не хотят, чтобы какие-то хапуги получили доступ к этим данным.
И здесь возникает парадокс: чем очевиднее и удобнее будет пользоваться таким сейфом, тем проще посторонним людям и алгоритмам догадаться, как его взломать.
Что же делать? Создавать интерфейс, который нелогичен, раздражает и даже немного издевается над пользователем.
Что это даёт? Это создаёт психологический и алгоритмический барьер не только для непрошеных гостей, но и для большинства автоматизированных методов взлома и анализа уязвимостей.
Здесь важно отметить: подобные приёмы мы применяем чаще всего именно на «первой миле» — этапе авторизации. Всё, что внутри, конечно, стараемся делать уже в относительно user-friendly формате. Но и там есть свои «фишки», но это уже больше про Zero-Trust архитектуру, поэтому пока не буду в это погружаться.
На практике всё выглядит ещё веселее, чем звучит в теории.
Небольшой дисклеймер
Описанные ниже методы – отличные инструменты для внутренних продуктов, где нет «внешних» пользователей. При этом именно индивидуальные виртуальные сейфы – прям самый лучший кейс использования подобного подхода, так как минимальный круг людей знает об особенностях системы и внутренняя кухня крайне маловероятно станет всеобщим достоянием.
Итак, приступим к изучению примеров использования User-Hostile подохода.
«Принцип Флешки» или Ложный отказ: сводим алгоритмы с ума
Одна из моих любимых находок — механизм авторизации с «ложным отрицанием». Когда пользователь при авторизации вводит правильную пару логин-пароль, система всегда отвечает ему, что «логин или пароль неверны». Для того, чтобы успешно войти в систему, необходимо еще раз ввести эту пару логин-пароль. В этот момент любой алгоритм перебора паролей сходит с ума, уверенный, что снова угадал неверно.
Приложение в приложении
Другой подход — «приложение в приложении». На первый взгляд это может быть безобидный сервис: заметки, каталог отелей, карты и маршруты. Введя неверный логин-пароль, вы спокойно изучаете туристические места, не вызывая подозрений. И лишь правильная пара логин-пароль плюс особое действие открывают доступ к реальному виртуальному сейфу. Даже если кто-то проверит историю вашего браузера или устройства, увидит лишь безобидную активность.
Но разумеется, что и над названиями URL надо подумать, чтобы совсем уже неприметно было, но это уже детали. Самый простой способ – НЕ делать человекочитаемые URLы.
Звучит странно? Возможно. Нелогично? Абсолютно. Но именно в этом и заключается сила такого подхода. Ведь эффективная защита зачастую строится не на технологических сложностях, а на психологических ловушках и нетривиальной логике.
Давайте взглянем ещё на несколько нестандартных решений, которые позволяют защитить систему от нежелательной авторизации. Главное — не забывать, что лучший способ скрыть дверь — это не ставить её там, где её будут искать.
И одна из таких прекрасных техник для усложнения жизни злоумышленников — фантомные разделы и ложные маршруты.
«Фантомные» разделы и ложные маршруты
Представьте, что вы залогинились в систему и видите стандартные разделы: «Документы», «Активы», «Финансы». Всё привычно и понятно. А теперь представьте, что кроме этих понятных разделов у вас есть ещё парочка абсолютно бесполезных и даже бессмысленных вкладок вроде «Служебная информация» или «Архив 2017». При попытке зайти туда, пользователь попадает в тупиковый лабиринт интерфейсов и форм.
Зачем такие «мертвые зоны»? Если кто-то посторонний получит доступ к системе, он будет вынужден потратить огромное количество времени на бессмысленные блуждания. Хуже того, у него постепенно сформируется ложная уверенность, что именно там спрятано что-то важное. А мы в это время, получив сигнал о том, что кто-то вляпался в фантомный раздел, успеем принять меры.
Это как с кошельком-приманкой, в котором нет ничего ценного, но его легко украсть. В итоге вор доволен, а владелец — ещё больше.
Ключи, которые работают только с «определённым» поведением пользователя
Ещё одна нетривиальная защита — ограничение доступа на основе поведения пользователя, а не только логина-пароля. Например, однажды мы спроектировали систему, которая предоставляла доступ к важнейшим данным только если пользователь проходил по очень нестандартному маршруту по интерфейсу:
открыл неочевидный раздел с отчётами;
затем вернулся на главную страницу;
после этого открыл «неважный» FAQ;
и только после этого переходил в раздел «Активы».
Звучит абсурдно, верно? Но именно такая странная логика «поведенческого ключа» создаёт непроницаемую защиту, потому что единственным человеком, кто вообще знает о существовании такой комбинации, является сам владелец системы.
Это почти как тайный стук в дверь подпольного бара эпохи сухого закона: если не знаешь ритм, дверь никогда не откроется.
Обезумевшая Captcha: вход, основанный на иррациональности
Система заранее задает явно нелогичные или абсурдные контрольные вопросы и ответы. Например, система просит выбрать все фотографии, где есть светофоры, однако, чтобы система тебя пропустила, нужно выбрать все фотографии, где этих светофоров нет. Вся фишка в том, что настоящие ответы — заведомо бессмысленны и известны только владельцу. Алгоритмы взлома, основанные на логике, ломаются о стену человеческой иррациональности.
Тихая проверка: скрытая многофакторная аутентификация
Вместо очевидных SMS-кодов или приложений-аутентификаторов можно использовать скрытые многофакторные проверки. Например, код подтверждения может прийти под видом обычной рассылки или уведомления о мероприятии, а настоящее письмо для входа выглядит абсолютно безобидным — например, как стандартное напоминание из календаря. Только настоящий пользователь знает, что именно это сообщение является ключом для доступа. Такие MFA-защиты практически невозможно перехватить, ведь посторонний даже не заподозрит наличие второго фактора.
Призрачный режим: динамические страницы входа
При каждом новом входе система генерирует уникальную, временную ссылку для авторизации или полностью меняет структуру страницы входа. Даже если злоумышленник каким-то образом сохранит страницу авторизации, воспользоваться ею повторно или автоматизировать атаки будет невозможно из-за постоянной смены адресов и структуры. Подобный подход отлично защищает от фишинга и автоматизированных атак.
Пароль в пароле: вариативная длина и скрытые шаблоны
Вместо фиксированной длины пароля пользователь может вводить любое количество символов, среди которых система будет искать лишь определённый шаблон. К примеру, если настоящий пароль abc123, то система примет и «xyzabc123def», и любой другой набор символов, содержащий ключевой фрагмент. Такой подход нивелирует эффективность клавиатурных шпионов и методов визуального перехвата.
Все перечисленные техники кажутся абсурдными или даже слегка сумасшедшими. Но именно поэтому они и работают. Давайте подведём итог.
Почему Worst Practice — это Best Practice?
Разумеется, описанные подходы не заменяют стандартные методы защиты вроде шифрования, но именно такие нестандартные приемы создают психологический барьер и делают вашу систему менее уязвимой для атак, основанных на типовых сценариях.
Так что, проектируя следующую систему, задумайтесь: а может быть, идеальный интерфейс — это тот, который кажется абсолютно бессмысленным для постороннего?
Как бы то ни было, помните главное: чтобы скрыть слона, не обязательно прятать его — иногда достаточно просто отвлечь внимание.
