Безопасность или удобство? Опыт команды авторизации и регистрации Авито

Ярослав Александров, Авито

Работа над безопасной регистрацией и входом в продукт — это непрерывный поиск баланса между удобством для пользователя и усложнением процесса аутентификации. Более жесткие требования к паролям или добавление нескольких этапов проверки могут повлечь за собой отток пользователей.

Ярослав Александров, руководитель юнита Avito ID, рассказал, как работать над безопасностью продукта, чтобы не оттолкнуть пользователей и максимально усложнить жизнь нарушителям.

Одна из моих команд занимается всеми сценариями, которые связаны с входом пользователя в личный кабинет: авторизация, регистрация, восстановление. С продуктовой точки зрения у нас две цели, которые могут вступать в противоречие:

  1. Мы хотим оптимизировать воронку регистрации и авторизации за счет доработки и создания новых функций, чтобы было удобно заходить в личный кабинет и как можно больше пользователей делало это. 
  2. Необходимо помнить про безопасность: снижать число попыток несанкционированного доступа к аккаунтам пользователей, не создавать уязвимости при добавлении новых фич. 

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

Подход Авито к работе с данными и метриками

На уровне компании в Avito исповедуется data-informed-подход к принятию решений: мы учитываем данные, стараемся проводить эксперименты, но также оставляем место для интуиции и разумного творчества.

С точки зрения работы с данными у нас есть серьезное преимущество перед многими компаниями: в продукте много пользователей и практически для любых сценариев мы можем провести количественные эксперименты, те же A/B-тесты, измерить влияние изменений. И в работе над безопасностью мы используем такой же подход: собираем сигналы о проблемах, генерируем гипотезы, пытаемся валидировать их на как можно более ранних стадиях, проверяем решения, которые прошли валидацию, приоритизируем и проверяем решения на данных и принимаем решение о выходе в продакшен. Это отличается от того подхода к безопасности, когда ставится задача просто пофиксить уязвимости и раскатить обновления на всех пользователей.

В работе над безопасностью отслеживается сразу два типа метрик: с одной стороны, есть метрики, которые помогают контролировать нарушения правил и вероятность несанкционированного доступа. Именно по ним мы в первую очередь отслеживаем эффекты от наших инициатив. С другой стороны, есть ключевые продуктовые метрики — их мониторинг позволяет понять, что мы не портим опыт пользователей: покупателей и продавцов. 

Это могут быть наши локальные показатели — например, процент авторизованных пользователей. Или глобальные метрики всей компании — например, общее количество покупателей и сделок, ключевые конверсии, ключевые действия на площадке (покупка, контакт). 

Как повышать безопасность, не ломая удобство

Слабые пароли — одна из главных точек приложения усилий злоумышленников, которые хотят получить доступ к аккаунтам пользователей. И это один из самых сложных вопросов с точки зрения прикладной безопасности. Понятно, что можно выставить максимально жесткие требования к паролям и заставить пользователя придумывать что-то очень сложное и заковыристое. И это на самом деле повысит безопасность — но сильно снизит качество пользовательского опыта.

Допустим, мы нашли какую-то точку воздействия, которая заметно снизит вероятность несанкционированных доступов на площадке. Например — усложнить требования к паролям. Следуя продуктовому подходу, мы оцениваем свои инициативы как с точки зрения влияния на целевую метрику (на сколько снизится возможность проникновений), так и с точки зрения влияния на ключевые метрики продукта. 

И мы всегда честно признаемся себе и пользователям, что новые ограничительные меры, которые повышают безопасность, одновременно добавляют неудобства для «хороших» пользователей. Важные метрики мы отслеживаем во время А/В-тестов и других экспериментов: так мы сразу видим, когда просадили ключевые пользовательские метрики, где и насколько смогли усложнить жизнь злоумышленникам. Однако кроме метрик мы учитываем и обращения в техподдержку от пользователей, которых мы задели своими ограничениями. такие жалобы для нас — тоже важные и опасные сигналы. А все сценарии проверяем с помощью UX-тестов.

При этом мы точно знаем, что нарушители часто стараются нагружать поддержку жалобами и обращениями, маскируясь под недовольных пользователей. Однако объединяя жалобы с данными мы можем видеть глубже, понимать общую картину. 

Да, любые дополнительные меры безопасности ломают опыт какого-то количества пользователей. А с другой стороны, уменьшая вероятность попадания недоброжелателей на площадку, мы делаем ее безопаснее — а значит, опыт пользователей мы, напротив, улучшаем. 

Конкретному пользователю Авито не особо критично сохранить безопасность своей учетки. Ему может быть проще установить простой пароль и махнуть рукой на безопасность: «Ну, взломают и взломают. Ничего страшного». Однако, если мы дадим злоумышленнику возможность проникнуть в учетную запись конкретного пользователя, он сможет от его имени общаться с другими под видом надежного продавца. И вроде бы пользователь, к чьему профилю получил доступ злоумышленник, особо не пострадал — но может быть безнадежно испорчен опыт использования площадки еще для многих людей. 

Для самого пользователя, потерявшего доступ к аккаунту, этот сценарий в итоге также становится травмирующим. Однако при регистрации профиля они не всегда думают о таких последствиях. 

Мы как платформа это понимаем, а значит наша ответственность — предотвращать подобные события. Поэтому учитывая все сигналы от пользователей, результаты исследований и данные аналитики, мы принимаем решение — раскатывать или нет какие-то ограничительные инициативы на весь Авито. И бывают очень сложные решения: например, если мы понимаем, что нужно локально потерять в деньгах и количестве пользователей, чтобы поднять уровень безопасности всей платформы. 

Конечно, какие-то ограничения мы стараемся смягчить за счет улучшения UX: например, в последние несколько месяцев мы существенно усложнили требования к паролям. И при этом параллельно прорабатывали схемы, которые бы помогали пользователям генерировать новые сложные пароли — упрощая опыт порядочных людей и одновременно минимизируя возможность внешнего проникновения. 

Часто мы разрабатываем новые, очень «технические» функции, которые должны перекрыть кислород злоумышленникам, — например, двухфакторную аутентификацию. И для таких фичей мы тоже используем чисто продуктовый подход: общаемся с пользователями, проводим customer development, подключаем аналитику и любые релевантные исследования, — чтобы составить как можно более полное представление об изменениях, взвесить все за и против и принять осознанное решение.

Как бизнес-цели конфликтуют с техническими методами 

До Авито я работал менеджером продуктов в компании, которая занимается информационной безопасностью — я занимался уязвимостями в приложениях. Например, мы брали какое-то банковское приложение и тестировали его на устойчивость к проникновениям. И за семь лет, пока я работал в той компании, заинтересованности компаний в безопасности своих приложений выросла в разы. Если 5−7 лет назад к нам обращались в основном банки и финансовые компании, то 2−3 года назад клиентами стали компании из всех рынков: путешествия, еда — да все что угодно. 

После тестов мы приходили в компанию и показывали критические уязвимости, которые надо исправить. Иногда представители заказчика возвращались и говорили, что бизнес заблокировал им изменения, потому что есть риск потерять много денег из-за оттока пользователей. Сейчас работая в Avito, я смог увидеть проблемы безопасности и со стороны бизнеса. 

Как обучение пользователей помогает повышать удобство продукта

Еще одно направление в работе над безопасностью продукта — образование пользователей, потому что есть серьезный разрыв между знаниями пользователей и развитием технологий или фичами продукта. Многие до сих пор считают безопасность и удобство полярными состояниями, хотя во многих случаях их научились объединять. Например, стереотипное представление о безопасном пароле — сочетание символов, которое максимально сложно запомнить.

Требования к паролю в экосистеме Apple
Требования к паролю в экосистеме Apple

Но формальные требования к паролям в итоге не работают.

Пример. В продукт внедряются серьезные требования к паролю: 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-коды. И подобные тренды рождаются почти каждый год. А значит, нам придется внедрять новые способы авторизации и улучшать их безопасность — ведь любая недоработка может создать уязвимость.

Кроме того, у нас есть и другие задачи — улучшать воронку входа, стараться упростить ее и так далее. То есть фокус циклически смещается с проблем безопасности на улучшение конверсии.

Дополнительные материалы

More Than Just Good Passwords? A Study on Usability and Security Perceptions of Risk-based Authentication

Добавить комментарий

ProductSense Academy — микрокурсы и 450+ докладов и кейсов по подписке Узнать больше