Двухфакторная аутентификация

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

Чтобы понять, что из себя представляет TOTP и как он используется, необходимо сначала кратко рассмотреть более базовые понятия. Первое из них двухфакторная аутентификация. Двухфакторная аутентификация (или многофакторная аутентификация) это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. Это означает, что после включения двухфакторной аутентификации пользователь должен пройти еще один шаг для успешного входа в систему. Стандартные шаги для входа в учетную запись это ввод логина и ввод пароля (рис.1).

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

В настоящее время существует два широко используемых метода получения одноразового пароля:

1. На основе SMS. Каждый раз, когда пользователь входит в систему, он получает на указанный в учетной записи номер мобильного телефона текстовое сообщение, которое содержит одноразовый пароль.

2. На основе TOTP. При включении двухфакторной аутентификации пользователю предлагается отсканировать QR-код с помощью специального приложения для смартфона, которое в дальнейшем постоянно генерирует одноразовый пароль для пользователя.

Метод на основе SMS не требует пояснений. Несмотря на свою простоту, он имеет ряд проблем. Например, ожидание SMS при каждой попытке входа в систему, проблемы с безопасностью и т. д. Вследствие чего NIST еще в 2016 году рекомендовала не использовать его в новых системах аутентификации. В связи с минусами метода на основе SMS, метод на основе TOTP становится популярным из-за его преимуществ.

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

• Знание, например, пароль

• Обладание (в физическом смысле), например, смартфон

• То, чем вы являетесь, например, биометрические данные

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

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

Для реализации двухфакторной аутентификации с использованием TOTP необходимо учитывать основное требование пароль должен создаваться на стороне пользователя, а также постоянно меняться.

Решение данной задачи может выглядеть следующим образом:

Когда пользователь включает двухфакторную аутентификацию, происходит следующее

1. Внутренний сервер создает секретный ключ для этого конкретного пользователя

2. Затем сервер передает этот секретный ключ телефонному приложению пользователя

3. Телефонное приложение инициализирует счетчик

4. Телефонное приложение генерирует одноразовый пароль, используя этот секретный ключ и счетчик

5. Телефонное приложение изменяет счетчик через определенный интервал и восстанавливает одноразовый пароль, делая его динамическим

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

HOTP переводится как Одноразовый пароль на основе HMAC. Этот алгоритм был опубликован инженерной группой Интернета (IETF) как RFC4226. HOTP определяет алгоритм создания одноразового пароля из секретного ключа и счетчика.

Этот алгоритм включает в себя два этапа:

• Создать хеш HMAC (используя алгоритм хеширования SHA-1) из секретного ключа и счетчика

hmacHash = HMAC-SHA-1 (секретный ключ, счетчик)

• В этом коде на выходе будет строка длиной 20 байт. Эта длинная строка не подходит в качестве одноразового пароля. Итак, нам нужен способ обрезать эту строку. HOTP определяет способ обрезать эту строку до желаемой длины

hmacHash[19] means 19th byte of the string.offset = hmacHash[19] & 0xf;truncatedHash = (hmacHash[offset++] & 0x7f) << 24 | (hmacHash[offset++] & 0xff) << 16 | (hmacHash[offset++] & 0xff) << 8 | (hmacHashh[offset++] & 0xff);finalOTP = (truncatedHash % (10 ^ numberOfDigitsRequiredInOTP));

В этом алгоритме мы сначала получаем смещение, которое является последними 4 битами hmacHash [19]. После этого мы объединяем байты из hmacHash [offset] в hmacHash [offset + 3] и сохраняем последний 31 бит в truncatedHash. Наконец, используя простую операцию по модулю, мы получаем одноразовый пароль разумной длины.

Это в значительной степени определяет алгоритм HOTP. Документ RFA4226 объясняет, почему это наиболее безопасный способ получить одноразовый пароль из этих двух значений.

Итак, мы нашли способ получить одноразовый пароль с помощью секретного ключа и счетчика. А как следить за счетчиком? Ответ на этот вопрос находится в TOTP. TOTP переводится как Одноразовый пароль на основе времени. Он был опубликован IETF как RFC6238. TOTP использует алгоритм HOTP для получения одноразового пароля. Единственная разница в том, что здесь вместо счетчика используется время, и это дает решение нашей проблемы. Это означает, что вместо инициализации счетчика и его отслеживания мы можем использовать время в качестве счетчика в алгоритме HOTP для получения OTP. Поскольку и сервер, и телефон имеют доступ ко времени, ни один из них не должен отслеживать счетчик. Кроме того, чтобы избежать проблемы с разными часовыми поясами сервера и телефона, мы можем использовать временную метку Unix, которая не зависит от часовых поясов. Однако время Unix определяется в секундах, поэтому оно меняется каждую секунду. Это означает, что сгенерированный пароль будет меняться каждую секунду, что не очень хорошо. Вместо этого нам нужно добавить значительный интервал перед изменением пароля. Например, приложение Google Authenticator меняет код каждые 30 секунд.

counter = currentUnixTime / 30

Итак, мы решили проблему счетчика. Теперь нам нужно решить нашу третью проблему: поделиться секретным ключом с приложением телефона. Здесь нам может помочь QR-код. Хотя есть возможность попросить пользователей вводить секретный ключ напрямую в приложение телефона, безопасность ключа зависит от его длины, и пользователю будет неудобно вводить такую длинную строку. Поскольку большинство смартфонов оснащено камерой, пользователь может использовать ее для того, чтобы отсканировать QR-код, и получить от него секретный ключ. Все, что для этого нужно преобразовать секретный ключ в QR-код и показать его пользователю. В настоящее время есть несколько бесплатных телефонных приложений (например, Google Authenticator App, Authy и т.д.), которые могут генерировать одноразовый пароль для пользователя. Поэтому в большинстве случаев создавать собственное телефонное приложение не нужно. Следующие псевдокоды объясняют способ реализации двухфакторной аутентификации на основе TOTP в веб-приложении.

When user request to enable 2-factor authentication// Generate a secret key of length 20.secretKey = generateSecretKey (20);// Save that secret key in database for this particular user. SaveUserSecretKey (userId, secretKey);// convert that secret key into qr image.qrCode = convertToQrCode (secretKey);// send the qr image as responseresponse (qrCode);

Пользователя просят отсканировать этот QR-код. Когда приложение телефона сканирует QR-код, оно получает секретный ключ пользователя. Используя этот секретный ключ, текущее время Unix и алгоритм HOTP, приложение телефона сгенерирует и отобразит пароль. Затем система просит пользователя ввести сгенерированный код после сканирования QR-кода. Это необходимо, чтобы убедиться, что пользователь успешно отсканировал изображение и приложение для телефона успешно сгенерировало код.

User types the code displayed in the application.// Fetch secret key from database.secretKey = getSecretKeyOfUser (userId);if (codeTypedByUser == getHOTP (secretKey, currentUnixTime / 30)) {enableTwoFactorAuthentication (userId);}

Здесь используется алгоритм HOTP на стороне сервера, чтобы получить аутентификацию на основе OTP по секретному ключу и текущему времени Unix. Если этот OTP совпадает с введенным пользователем, то появляется возможность включить двухфакторную аутентификацию для этого пользователя. Теперь, после каждой операции входа в систему, проверяется, включена ли для этого конкретного пользователя двухфакторная аутентификация. Если да, то запрашивается одноразовый пароль, отображаемый в приложении телефона. И если этот набранный код правильный, только тогда пользователь аутентифицируется.

User types the code displayed in the phone application to login// Fetch secret key from database.secretKey = getSecretKeyOfUser (userId);if (codeTypedByUser == getHOTP (secretKey, currentUnixTime)) {signIn (userId);}

Если пользователь потеряет код, есть несколько способов помочь пользователю восстановить его. Обычно, когда они включают двухфакторную аутентификацию, есть возможность показать секретный ключ вместе с QR-кодом и попросить их сохранить этот код в безопасном месте. Такие приложения, как Google Authenticator App, позволяют сгенерировать пароль путем прямого ввода секретного ключа. Если пользователь потеряет код, он может ввести этот надежно сохраненный секретный ключ в приложение телефона, чтобы снова сгенерировать одноразовый пароль. При наличии номера телефона пользователя возможно использовать метод на основе SMS, чтобы отправить пользователю одноразовый пароль, чтобы помочь ему восстановить код.

Двухфакторная аутентификация набирает популярность. Многие веб-приложения реализуют его для дополнительной безопасности. В отличие от метода на основе SMS, метод TOTP также не требует особых усилий. Так что эту функцию стоит реализовать для любого приложения.

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

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

Отправка SMS на короткий номер

Первый вариант верификации был через отправку пользователем исходящего sms на короткий номер. Люди отправляли сообщение на самый дешевый короткий номер, тем самым подтверждали свой. В 2010 году это казалось решением проблемы, не требующим существенных затрат. Мы были одни из первых, кто это внедрил, а тогда больше половины пользователей принципиально не хотели светить свой номер мобильного телефона. Мало того, отправка на номер для пользователя была платной, хоть и минимальной стоимости около 2 (сумму забирал себе оператор), и требовала дополнительного действия. Вдобавок: поддерживались не все операторы, а сами короткие номера тогда часто ассоциировались с мошенниками. Хлынули жалобы, конверсия регистраций упала. Стало понятно, что решение выбрано неудачно.

Подтверждение SMS с кодом

Решили внедрить отправку клиенту sms с кодом. Несмотря на существенные расходы в пределах 50000 (около 1,500$ по тому курсу) на подтверждения и восстановления паролей, команда вздохнула с облегчением и о проблеме надолго забыли. Время и трудозатраты на борьбу со спамерами изматывали сильнее, чем дополнительные расходы.

Всё изменилось ближе к 2015 году, когда сотовые операторы ввели интерконнект. До этого исходящие сообщения стоили очень дешево (от 10 копеек) из-за возможности отправлять смски через региональных операторов в обход прямых подключений, не теряя в качестве доставки. После интерконнекта операторы стали блокировать отправку sms из других сетей своим абонентам, если она происходила от незарегистрированного имени отправителя. У заказчиков и агрегаторов не было выхода, кроме как подключаться напрямую и отправлять через прямые официальные каналы, которые в целом были всегда, но стоили до 10 раз дороже. Для усиления эффекта основные операторы выкупили почти всех тех мелких, через которых можно было отправлять сообщения дешево. Когда рынок стал монополизирован, операторы еще сильнее подняли цены на смски и продолжают это делать каждый год.

После повышения цен затраты увеличились на порядок: до 300000-400000 в месяц. Рост количества пользователей и платные плюшки ещё позволяли нести такие издержки, но шутки про то, что затраты на sms превышают затраты на несколько десятков серверов уже перестали быть смешными. Но других вариантов не было: безопасность аккаунта и блокировка спамеров важнее, приходилось платить.

Тем временем география пользователей расширилась за пределы России, в первую очередь за счет СНГ. А это, в свою очередь, совпало с желанием заработать и у операторов соседних стран: Украина, Беларусь, Казахстан, Киргизия и других. Они решили, что 1-2 за sms это не предел, давайте повысим до 7-13! Так было введено разделение трафика на национальный и международный с разницей в несколько раз.

Под международный трафик автоматически попадают все известные международные бренды, все проекты, которые не имеют в данной стране юр.лица и национального домена. Некоторые страны (особенно Казахстан) еще изобретательнее подошли к вопросу: если у проекта есть сайт в другой доменной зоне (например, не только site.kz, но еще и .ru), проект не может быть согласован по национальному тарифу, несмотря на то, что sms отправляются от имени местного проекта и только по Казахстану местным жителям. Попробуешь обойти огромный штраф и блокировка имени.

Звонок с кодом голосом

Расходы на sms перевалили за психологический барьер 1 млн в месяц, что само по себе всерьез заставляло задуматься над альтернативами. Но вместе с ростом расходов вернулась и старая проблема в новом обличии. Теперь благодаря куче ?сервисов по приему sms в выдаче Яндекса на виртуальные номера стало легко зарегистрировать аккаунт для любой социальной сети, включая VK и Facebook.

Так мы начали работать над аутентификацией через звонки. Идея пришла к нам несколько лет назад и была внедрена как дополнительный резервный способ подтверждения номера для некоторых стран. Действие от клиента требовалось такое же, как с sms ввести код, который мы отправляем, только в случае со звонками код диктовался голосом при ответе на звонок.

Но и тут есть подводные камни: по России и некоторым странам звонки работают хорошо, но из-за международной тарификации стоимость минуты по некоторым направлениям превышает 20-30 (например: Беларусь, Украина и др). Вторая проблема качество доставки: операторы могут фильтровать трафик по длительности соединения. Звонки определяются операторами, как спам и фильтруются, а значит пользователь не получает свой код подтверждения.

Еще был Viber :)

И предупреждение с угрозой штрафа в 5000 евро за отправку запрещенного контента. Пока мы тестировали новый способ и часть пользователей получали приветственное сообщение при регистрации вида Здравствуйте, %username%!, пранкеры подсуетились и начали оформлять левые регистрации на чужие номера. Людям пришли сообщения вида Здравствуйте, Жопа:

Заметили быстро и лавочку прикрыли, но собрали негатив. Сам же Viber показал низкое проникновение (порядка 15-25%) и экономическую нецелесообразность из-за минимального платежа в ~30000, который сгорает в конце месяца, если пакет услуг на эту сумму, при цене сервисного сообщения в ~50 копеек, не был использован.

Звонок с кодом в номере

В итоге пришли к подтверждению регистраций звонком без соединения, когда кодом являются последние 4 цифры номера, с которого происходит звонок пользователю.

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

Стало понятно, что гарантия доставки может быть лишь при наличии своих пулов номеров и белых каналов, а значит и экономии в 20 раз не получится. В партнерстве с greensms.ru под нас запустили сервис со своими номерами и резервными каналами, а позже добавили в API и выложили SDK к нему на разных языках на GitHub. В процессе оказалось, что даже при нулевой продолжительности соединения с абонентом, вышестоящие операторы связи произвольно тарифицируют количество секунд разговора (кстати, кто сталкивался с подобным и смог решить это с оператором или на стороне Asterisk напишите, пожалуйста, в комментариях).В итоге удалось добиться стабильных результатов при стоимости в 40-60 копеек.

Сначала пользователи встретили нововведения замешательством. Конверсия при использовании sms >95%, звонки сейчас показывают ~85%. Еще год назад конверсия была, примерно на 10% хуже, но стала расти по мере распространенности метода и с изменениями в интерфейсе.

Люди не понимали, где брать 4 цифры, в каком номере, сбрасывали вызов, запрашивали повторный и потом всё равно обращались в поддержку, приходилось всё объяснять, показывать.

Сейчас проще: всё больше проектов используют этот способ, люди привыкли и не так удивляются. Кстати, теперь еще и Яндекс их внедрил для подтверждения номера при входе на новом устройстве в свой аккаунт.

Совет: обязательно размещать рядом с полем ввода цифр скриншот телефона с выделенными 4 цифрами, которые нужно будет ввести пользователю.
Где допустимо стоит подключать автоматическое считывание цифр номера при регистрации из приложения.

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

Финальная битва между добром и интернетом

А не будет её финальной. Чем популярнее становится сервис, тем больше желающих использовать его в плохих целях. И на новые методы защиты находятся новые методы нападения. Так что ждем новых ухищрений, может с помощью eSIM?

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