Работа над безопасной регистрацией и входом в продукт — это непрерывный поиск баланса между удобством для пользователя и усложнением процесса аутентификации. Более жесткие требования к паролям или добавление нескольких этапов проверки могут повлечь за собой отток пользователей.
Ярослав Александров, руководитель юнита Avito ID, рассказал, как работать над безопасностью продукта, чтобы не оттолкнуть пользователей и максимально усложнить жизнь нарушителям.
Одна из моих команд занимается всеми сценариями, которые связаны с входом пользователя в личный кабинет: авторизация, регистрация, восстановление. С продуктовой точки зрения у нас две цели, которые могут вступать в противоречие:
- Мы хотим оптимизировать воронку регистрации и авторизации за счет доработки и создания новых функций, чтобы было удобно заходить в личный кабинет и как можно больше пользователей делало это.
- Необходимо помнить про безопасность: снижать число попыток несанкционированного доступа к аккаунтам пользователей, не создавать уязвимости при добавлении новых фич.
Помимо процессов авторизации и регистрации я участвую в разных инициативах по борьбе с нарушителями на площадке. И здесь тоже важно балансировать между простотой и удобством для пользователя и безопасностью.
Подход Авито к работе с данными и метриками
На уровне компании в Avito исповедуется data-informed-подход к принятию решений: мы учитываем данные, стараемся проводить эксперименты, но также оставляем место для интуиции и разумного творчества.
С точки зрения работы с данными у нас есть серьезное преимущество перед многими компаниями: в продукте много пользователей и практически для любых сценариев мы можем провести количественные эксперименты, те же A/B-тесты, измерить влияние изменений. И в работе над безопасностью мы используем такой же подход: собираем сигналы о проблемах, генерируем гипотезы, пытаемся валидировать их на как можно более ранних стадиях, проверяем решения, которые прошли валидацию, приоритизируем и проверяем решения на данных и принимаем решение о выходе в продакшен. Это отличается от того подхода к безопасности, когда ставится задача просто пофиксить уязвимости и раскатить обновления на всех пользователей.
В работе над безопасностью отслеживается сразу два типа метрик: с одной стороны, есть метрики, которые помогают контролировать нарушения правил и вероятность несанкционированного доступа. Именно по ним мы в первую очередь отслеживаем эффекты от наших инициатив. С другой стороны, есть ключевые продуктовые метрики — их мониторинг позволяет понять, что мы не портим опыт пользователей: покупателей и продавцов.
Это могут быть наши локальные показатели — например, процент авторизованных пользователей. Или глобальные метрики всей компании — например, общее количество покупателей и сделок, ключевые конверсии, ключевые действия на площадке (покупка, контакт).
Как повышать безопасность, не ломая удобство
Слабые пароли — одна из главных точек приложения усилий злоумышленников, которые хотят получить доступ к аккаунтам пользователей. И это один из самых сложных вопросов с точки зрения прикладной безопасности. Понятно, что можно выставить максимально жесткие требования к паролям и заставить пользователя придумывать что-то очень сложное и заковыристое. И это на самом деле повысит безопасность — но сильно снизит качество пользовательского опыта.
Допустим, мы нашли какую-то точку воздействия, которая заметно снизит вероятность несанкционированных доступов на площадке. Например — усложнить требования к паролям. Следуя продуктовому подходу, мы оцениваем свои инициативы как с точки зрения влияния на целевую метрику (на сколько снизится возможность проникновений), так и с точки зрения влияния на ключевые метрики продукта.
И мы всегда честно признаемся себе и пользователям, что новые ограничительные меры, которые повышают безопасность, одновременно добавляют неудобства для «хороших» пользователей. Важные метрики мы отслеживаем во время А/В-тестов и других экспериментов: так мы сразу видим, когда просадили ключевые пользовательские метрики, где и насколько смогли усложнить жизнь злоумышленникам. Однако кроме метрик мы учитываем и обращения в техподдержку от пользователей, которых мы задели своими ограничениями. такие жалобы для нас — тоже важные и опасные сигналы. А все сценарии проверяем с помощью UX-тестов.
При этом мы точно знаем, что нарушители часто стараются нагружать поддержку жалобами и обращениями, маскируясь под недовольных пользователей. Однако объединяя жалобы с данными мы можем видеть глубже, понимать общую картину.
Да, любые дополнительные меры безопасности ломают опыт какого-то количества пользователей. А с другой стороны, уменьшая вероятность попадания недоброжелателей на площадку, мы делаем ее безопаснее — а значит, опыт пользователей мы, напротив, улучшаем.
Конкретному пользователю Авито не особо критично сохранить безопасность своей учетки. Ему может быть проще установить простой пароль и махнуть рукой на безопасность: «Ну, взломают и взломают. Ничего страшного». Однако, если мы дадим злоумышленнику возможность проникнуть в учетную запись конкретного пользователя, он сможет от его имени общаться с другими под видом надежного продавца. И вроде бы пользователь, к чьему профилю получил доступ злоумышленник, особо не пострадал — но может быть безнадежно испорчен опыт использования площадки еще для многих людей.
Для самого пользователя, потерявшего доступ к аккаунту, этот сценарий в итоге также становится травмирующим. Однако при регистрации профиля они не всегда думают о таких последствиях.
Мы как платформа это понимаем, а значит наша ответственность — предотвращать подобные события. Поэтому учитывая все сигналы от пользователей, результаты исследований и данные аналитики, мы принимаем решение — раскатывать или нет какие-то ограничительные инициативы на весь Авито. И бывают очень сложные решения: например, если мы понимаем, что нужно локально потерять в деньгах и количестве пользователей, чтобы поднять уровень безопасности всей платформы.
Конечно, какие-то ограничения мы стараемся смягчить за счет улучшения UX: например, в последние несколько месяцев мы существенно усложнили требования к паролям. И при этом параллельно прорабатывали схемы, которые бы помогали пользователям генерировать новые сложные пароли — упрощая опыт порядочных людей и одновременно минимизируя возможность внешнего проникновения.
Часто мы разрабатываем новые, очень «технические» функции, которые должны перекрыть кислород злоумышленникам, — например, двухфакторную аутентификацию. И для таких фичей мы тоже используем чисто продуктовый подход: общаемся с пользователями, проводим customer development, подключаем аналитику и любые релевантные исследования, — чтобы составить как можно более полное представление об изменениях, взвесить все за и против и принять осознанное решение.
Как бизнес-цели конфликтуют с техническими методами
До Авито я работал менеджером продуктов в компании, которая занимается информационной безопасностью — я занимался уязвимостями в приложениях. Например, мы брали какое-то банковское приложение и тестировали его на устойчивость к проникновениям. И за семь лет, пока я работал в той компании, заинтересованности компаний в безопасности своих приложений выросла в разы. Если 5−7 лет назад к нам обращались в основном банки и финансовые компании, то 2−3 года назад клиентами стали компании из всех рынков: путешествия, еда — да все что угодно.
После тестов мы приходили в компанию и показывали критические уязвимости, которые надо исправить. Иногда представители заказчика возвращались и говорили, что бизнес заблокировал им изменения, потому что есть риск потерять много денег из-за оттока пользователей. Сейчас работая в Avito, я смог увидеть проблемы безопасности и со стороны бизнеса.
Как обучение пользователей помогает повышать удобство продукта
Еще одно направление в работе над безопасностью продукта — образование пользователей, потому что есть серьезный разрыв между знаниями пользователей и развитием технологий или фичами продукта. Многие до сих пор считают безопасность и удобство полярными состояниями, хотя во многих случаях их научились объединять. Например, стереотипное представление о безопасном пароле — сочетание символов, которое максимально сложно запомнить.
Но формальные требования к паролям в итоге не работают.
Пример. В продукт внедряются серьезные требования к паролю: 12 символов, большие и маленькие буквы, спецсимволы, цифры. Вроде бы, все отлично — не придерешься. Безопасность на уровне. А пользователь берет слово password, qwerty, Avito и год рождения — потом заменит «А» на @, первую латинскую букву сделаем заглавной и добавит в конце цифру 1. И все равно создаст пароль, который легко запомнить. А ведь все эти схемы злоумышленники очень хорошо знают — и на раз могут подобрать вроде бы сложные пароли.
Конечно, и в Avito, и в других крупных сервисах стоит серьезная защита от brute force (метод атаки, когда перебираются все возможные варианты логинов и паролей) на всех уровнях — продуктовых, технических, сетевых. Но это не значит, что можно использовать пароль, который легко угадать со 2-3 попытки подобрать за 2−3 попытки — а пароль, пример которого я привел, как раз можно подобрать за несколько попыток. На большом массиве пользователей обязательно будет конверсия.
Поэтому мы внедряем более сложные требования к паролям и одновременно пытаемся рассказать пользователям, что по-настоящему сложный и безопасный пароль легко создать и запомнить. Например, можно взять три случайных слова на английском или на русском (транслитом) и сделать из них одну фразу — только между этими словами не должно быть какой-то очевидной для всех связи: zebra, obezyana, arbuz.
Запомнить такой пароль гораздо проще случайного сочетания символов, а вот мошенникам придется серьезно потрудиться, чтобы получить доступ к аккаунту— это доказано и с точки зрения математики. То есть в этом случае мы уходим от однозначного противопоставления безопасности и удобства.
Советы о том, как составить надежный пароль, мы упаковываем в полезные статьи. Вот пример — «Защитить профиль от взлома».
Казалось бы, мы работаем с чисто техническими задачами, но используем стандартные продуктовые методы, фреймворки и инструменты, как и в разработке бизнес-фич.
Процесс: как в Авито внедряли двухфакторную аутентификацию
Когда мы разрабатывали средства двухфакторной авторизации (2FA), то в первую очередь общались с пользователями, проводили стандартные глубинные интервью. Выясняли, как пользователи относятся к безопасности своих аккаунтов, что для них важно, как они принимают решение, включать или не включать двухфакторную авторизацию в аккаунте, как они обычно работают с паролями.
Из интересного: Когда люди включают 2FA? Когда их где-нибудь взломали, когда учетка становится ценной, когда прочитали где-то в интернете, что к их аккаунту может получить доступ посторонний. Люди беспокоятся в первую очередь о своей репутации — что от их имени кого-то обманут.
Мы прекрасно понимали, что двухфакторная авторизация иногда необходима — чтобы улучшать безопасность платформы. С другой стороны, мы знали, что большинство методов двухфакторной авторизации работают плохо — портят пользовательский опыт. При этом мы выяснили, что оптимальный и наиболее сбалансированный с точки зрения безопасности и удобства метод двухфакторной авторизации — это risk based authentication (RBA). То есть когда двухфакторная авторизация включается, только если система подозревает, что происходит внешнее проникновение (очень упрощенное объяснение).
И тогда мы практически не создаем лишних действий для хороших пользователей, но заметно снижаем вероятность получения доступа к аккаунтам со стороны нарушителей. А значит, у нас получилось соблюсти правильный баланс между удобством и безопасностью, между продуктовым подходом и необходимостью закрыть потенциально опасные сценарии.
Результат: усложнение требований к паролям и введение RBA 2FA позволило снизить вероятность получения доступов нарушителями к аккаунтам пользователей в несколько раз, при этом оттока не было.
Злоумышленники могут использовать также методы социальной инженерии Это когда сами пользователи так или иначе помогают нарушителям получить доступ к информации, например, сообщают пароль по телефону. Да, такой способ уже почти не работает, но мошенники очень изобретательны: постоянно придумывают какие-то новые методы, чтобы обмануть пользователей. Полностью победить это практически невозможно — потому что срабатывает человеческий фактор, то, что не связано с технической начинкой самого продукта.
Казалось бы, проблема тут не на нашей стороне, но у нас есть ответственность перед своими пользователями. Поэтому продолжаем их обучать, рассказывать им о том, как вести себя, чтобы не попасть под влияние нарушителей, а также с помощью обновлений продукта снижаем вероятность подобных случаев.
Чек-лист: с помощью каких каналов можно организовать двухфакторную авторизацию
- SMS
- Пуш-уведомления в приложении
- Звонок на телефон
- продиктовать код;
- попросить ввести последние четыре цифры номера, с которого вам звонили;
- пользователь сам должен позвонить с указанного в аккаунте номера на специальный телефон.
- TOTP (Time-based One-Time Password Algorithm) — OATH-алгоритм создания одноразовых паролей для защищенной аутентификации
- QR-код, который надо отсканировать из приложения, чтобы войти в систему
- Имейл — специальный код или ссылка для подтверждения присылается на электронную почту
- Внутренний мессенджер приложения Авито (похожая механика есть в Telegram)
- Биометрия — отпечаток пальца или сканирование лица
- Список одноразовых паролей (использовался в Сбере)
- Физические ключи (аппаратный токен, USB-ключ, криптографический токен)
- Пин-код — когда вход в систему осуществляется по SMS
Почему над авторизацией работает целая команда
Любой продукт всегда развивается и улучшается, а безопасность – это обратная сторона развития продукта. Например, над авторизацией и регистрацией у нас работает целая продуктовая команда: исследователи, аналитики, менеджеры продуктов, инженеры. И когда к нам на собеседование приходят кандидаты, они удивляются: зачем столько людей? Ведь по ощущениям все просто: ввел логин и пароль в простую форму, авторизовался. Что там поддерживать целой командой?
Однако это обманчивая простота: наш бэклог забит задачами на несколько лет вперед — и при этом мы уже работаем не один год. Почему так? С одной стороны, в сценариях регистрации и авторизации очень много разветвлений. С другой стороны, это «передний край» продукта, препятствие, которое надо преодолеть, чтобы получить доступ к ключевым действиям: запросить контакт продавца, пообщаться с ним в мессенджере, найти и выбрать товар. В итоге любое изменение авторизации влияет на все ключевые метрики продукта — в лучшую или худшую сторону.
Еще один фактор — каждый год появляются новые тренды в регистрации и авторизации. Например, сейчас набирает обороты авторизация через QR-коды. И подобные тренды рождаются почти каждый год. А значит, нам придется внедрять новые способы авторизации и улучшать их безопасность — ведь любая недоработка может создать уязвимость.
Кроме того, у нас есть и другие задачи — улучшать воронку входа, стараться упростить ее и так далее. То есть фокус циклически смещается с проблем безопасности на улучшение конверсии.
