Плохая проработка сценария аутентификации. Или нет?

На глаза попалась статья о том, как молодой банк запустил веб-приложение для обслуживания клиентов. Я — директор по маркетингу RooX (специализируемся на аутентификации и авторизации внешних пользователей), так что мне стало интересно, как банк реализовал вход. Я не являюсь клиентом этого банка. Этот факт стал катализатором исследования.
-
В веб-версии логин — это номер телефона.
-
Проверка на формат мобильного номера отрабатывает нормально — клавиатура откликается только на цифры, код +7 предпроставлен, больше 9 цифр ввести нельзя, при недостатке цифр появляется подсказка «Введи мобильный телефон» (можно было бы «Не хватает цифр в номере»).
-
Форма принимает номер не-клиента как должное. Кнопка «Продолжить» активна. Ведет на страницу ввода кода.
- При вводе нескольких случайных номеров телефона капча ни разу себя не проявила.
- Пришло sms c кодом подтверждения.
- Блокировка перебора кода сработала после 6 или 7 неправильных комбинаций, отправили «на скамейку запасных» на 5 минут.
- После ввода правильного кода перебросило на девственно белую страницу. Пожалуй, это был первый намек, что я не клиент )
-
Некоторое время на любую попытку «а давайте снова войдем» сразу, без промежуточных просьб ввести телефон и код, показывалась девственно белая страница. Куда-то меня всё же залогинило )
-
Сотрудник банка перезвонил довольно быстро: «Вы оставили номер телефона, но не указали данные о компании». Обсудили, как такое произошло )
Казалось бы, сценарий «пришел не-клиент» недостаточно отработан: при вводе номера телефона не-клиента не отреагировали, на смску потратились, залогинили в никуда. Однако...
-
Кейс «Потенциальный клиент логинится в личный кабинет, минуя регистрацию» не самый, честно скажем, частый случай поведения ЦА. При запуске MVP ресурсы на реализацию этого сценария можно не тратить.
-
Информировать при вводе телефона «ой, вы же не клиент» плохо с точки зрения инфобеза. Злоумышленник может, зная телефон, точечно его проверить. А если капчи нет, может перебором составить базу телефонов клиентов.
-
Отправить sms-код для входа не-клиенту — вполне рабочий ход. Человека можно залогинить в зону «уже-почти-клиент» и дальше прогревать его до клиента. Этого не произошло, но могло бы.
-
В никуда логинить нехорошо, да. Скорее всего, это произошло следующим образом. Система аутентификации проверила OTP (код по sms) и выдала токен с номером телефона. В ДБО не было такого пользователя, но это уже, как говорится, не проблемы шерифа. Но есть и светлая сторона. В описанном поведении сайта есть косвенные признаки того, что система аутентификации отделена от системы ДБО, что круто с точки зрения дальнейшего развития и поддержки обеих систем.
-
Сотрудник позвонил. И если бы я была странным человеком из п. 1, меня бы отловили и попытались сделать клиентом.
-
Личному кабинету не хватает зоны для приземления не-клиентов.
-
Текущая реализация входа может быть уязвима в случае, если кто-то очень хочет разорить банк на sms.
- Если и дальнейшие операции проводятся с подтверждением по одному фактору (тем более, по sms), то это уже противоречит требованиям безопасности ЦБ.
Источник: VC.ru
Наш PR-кейс вошел в шорт-лист "Инфоповодов 2022 года" в ИТ по версии "Медиалогии"
3 марта 2023"Медиалогия" ежегодно рейтингует PR-кейсы по количеству публикаций в СМИ.
iTrend запустил серию прямых эфиров с ИТ-гостями - первый подкаст уже готов
17 февраля 2023Слушайте или смотрите наш разговор про глобальный рынок в ИТ
Выступаем на SOCIAL MEDIA FEST – 2023
9 февраля 2023Приглашаем в Пресс-центр iTrend – место встречи в Telegram для медиа и IT-компаний
9 февраля 2023Наш пресс-центр – это инструмент для удобного взаимодействия между двумя сторонами.
Вышел свежий подкаст с основателями iTrend: Павлом Житнюком и Асей Власовой
8 февраля 2023Поговорили о бизнесе в ИТ, new media, продвижении в странах СНГ, о жизни и книжках