отправить код через sms

Организация аутентификации по СМС по примеру Telegram/Viber/WhatsApp

Представим, что перед вами стоит задача организовать аутентификацию пользователя (в мобильном приложении, в первую очередь) так, как это сделано в Telegram/Viber/WhatsApp. А именно реализовать в API возможность осуществить следующие шаги:

Мне потребовалось некоторое количество времени, чтобы осознать, как правильно это сделать. Моя задача — поделиться наработанным с вами в надежде, что это сэкономит кому-то времени.

Я постараюсь кратко изложить выработанный подход к этому вопросу. Подразумевается, что у вас API, HTTPS и, вероятно, REST. Какой у вас там набор остальных технологий неважно. Если интересно — добро пожаловать под кат.

Мы поговорим о тех изменениях, которые следует проделать в API, о том, как реализовать одноразовые пароли на сервере, как обеспечить безопасность (в т.ч. защиту от перебора) и в какую сторону смотреть при реализации это функциональности на мобильном клиенте.

Изменения в API

В сущности требуется добавить три метода в ваше API:

1. Запросить СМС с кодом на номер, в ответ — токен для последующих действий.

Действие соответствует CREATE в CRUD.

Если всё прошло, как ожидается, возвращаем код состояния 200.

Если же нет, то есть одно разумное исключение (помимо стандартной 500 ошибки при проблемах на сервере и т.п. — некорректно указан телефон. В этом случае:

HTTP код состояния: 422 (Unprocessable Entity), в теле ответа: PHONE_NUMBER_INVALID.

2. Подтвердить токен с помощью кода из СМС.

Действие соответствует UPDATE в CRUD.

Аналогично. Если всё ок — код 200.

Если же нет, то варианты исключений:

3. Форсированная отправка кода повторно.

Аналогично. Если всё ок — код 200.

Если же нет, то варианты исключений:

Особенности реализации одноразовых паролей

Вам потребуется хранить специальный ключ для проверки СМС-кодов. Существует алгоритм TOTP, который, цитирую Википедию:

OATH-алгоритм создания одноразовых паролей для защищенной аутентификации, являющийся улучшением HOTP (HMAC-Based One-Time Password Algorithm). Является алгоритмом односторонней аутентификации — сервер удостоверяется в подлинности клиента. Главное отличие TOTP от HOTP это генерация пароля на основе времени, то есть время является параметром[1]. При этом обычно используется не точное указание времени, а текущий интервал с установленными заранее границами (например, 30 секунд).

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

Пример кода на руби, чтобы было понятно о чём речь:

Алгоритм описан в стандарте RFC6238, и существует масса реализацией этого алгоритма для многих языков: для Ruby и Rails, для Python, для PHP и т.д..

Строго говоря, Telegram и компания не используют TOTP, т.к. при регистрации там, вас не ограничивают по времени 30-ю секундами. В связи с этим предлагается рассмотреть альтернативный алгоритм OTP, который выдает разные пароли, базируясь на неком счётчике, но не на времени. Встречаем, HOTP:

HOTP (HMAC-Based One-Time Password Algorithm) — алгоритм защищенной аутентификации с использованием одноразового пароля (One Time Password, OTP). Основан на HMAC (SHA-1). Является алгоритмом односторонней аутентификации, а именно: сервер производит аутентификацию клиента.
…
HOTP генерирует ключ на основе разделяемого секрета и не зависящего от времени счетчика.

HOTP описан в стандарте RFC4226 и поддерживается тем же набором библиотек, что представлен выше. Пример кода на руби:

Безопасность решения

Первое непреложное само собой разумеющееся правило: ваше API, где туда-сюда гуляют данные и, самое главное, token должно быть завернуто в SSL. Поэтому только HTTPS, никакого HTTP.

Далее, самым очевидным вектором атаки является прямой перебор. Вот что пишут в параграфе 7.3 авторы стандарта HOTP (на котором базируется TOTP) на эту тему:

Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.

We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.

Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.

The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.

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

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

Мнение, что можно полагаться только на то, что код живёт ограниченное число секунд, и будет безопасно, т.к. код сбрасывается — ошибочно. Даже, если есть фиксированное ограничение на число попыток в секунду.

Посмотрим на примере. Пусть код TOTP состоит из 6 цифр — это 1000000 возможных вариантов. И пусть разрешено вводить 1 код в 1 секунду, а код живёт 30 секунд.

Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000

0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880

8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.

Так что надо чётко осознавать, что необходимо реализовать хотя бы одну (а лучше обе) меры, предложенные авторами стандарта.

Не стоит забывать и о стойкости ключа. Авторы в параграфе 4 обязывают длину ключа быть не менее 128 бит, а рекомендованную длину устанавливают в 160 бит (на данный момент неатакуемая длина ключа).

R6 — The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.

Изменения в схеме БД

Итого, в модели (или в таблице БД, если угодно) надо хранить:

Особенности реализации мобильного приложения

В случае Android полученный токен можно хранить в SharedPreferences (почему не AccountManager), а для iOS в KeyChain. См. обсуждение на SoF.

Заключение

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

Источник

Отправка кодов и паролей по СМС

Если у вас нет ИП или юридического лица, то вы не можете совершать СМС рассылки через наш сервис. Но вы можете отправлять коды и пароли для авторизации вашим пользователям в виде СМС.

Как это работает?

Если мы определяем, что вы отправляете СМС с кодом или паролем (например ваше сообщение: Ваш код: 1265665 ), то мы удаляем любой текст, оставляя только код ( 1265665 ), и отправляем его с нашего отправителя SMS.RU. Это гарантирует доставку вашего кода получателям, если вы по какой-то причине не создали своего отправителя или не заключили с нами договор. В некоторых случаях это также позволяет сэкономить на отправке СМС сообщения.

Эта опция также гарантирует доставку на международные направления, куда обычные сообщения могут доставляться с проблемами.

Чтобы эта система работала, код должен быть не длиннее 10 символов.

Но если я хочу своего отправителя, и чтобы текст не менялся?

Для этого нужно создать буквенного отправителя в разделе «Отправители», заключить с нами договор от юридического лица или ИП в разделе «Юридическим лицам» и прикрепить гарантийные письма к отправителю в разделе «Отправители» (их можно будет скачать там и они уже будут заполнены вашими реквизитами).

Как отключить эту возможность целиком?

Нужно зайти в раздел «Настройки» и отключить галочку у опции «Оптимизировать отправку кодов и паролей».

Последнее обновление: 11 Октября 2019 в 10:11

Источник

У всех с сегодняшнего дня строка «Отправить код через sms» не кликабельна?

Медали

особенно актуально, если сидишь со слабых проксей

Сервисы для ЛС в ВК без банов (пиши ЛС)

Медали

Медали

Место свободное для рекламы

мб реал инет не вывозит ну иль прокся

Ищу инвестора.

особенно актуально, если сидишь со слабых проксей

Нет, все грузится. Пробовал на работе, дома.

Кэш браузера попробовать почистить

Новый профиль в мазилле, смысла нет

мб реал инет не вывозит ну иль прокся

прокси менял, перебрал кучу просто

Пробовал без прокси тоже, вбил не вирт. номер, поменял кучу браузеров. Поэтому и спрашиваю, у всех проблемы или нет?

Источник

Отправить СМС сообщение HTTP запросом

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

Примеры запросов

Отправить один текст на один или несколько номеров, указанных через запятую:

Отправить разный текст на разные номера:

Пример ответа

При включенном параметре json=1:

Параметры

Авторизация осуществляется при помощи:

Отправка СМС из PHP (со включенным модулем curl)

Мы настоятельно рекомендуем использовать нашу библиотеку под PHP. Данный код указан только в качестве простого примера.

Отправка СМС из PHP без curl

Мы настоятельно рекомендуем использовать нашу библиотеку под PHP. Данный код указан только в качестве простого примера.

Отправка СМС из Perl

Отправка СМС из командной строки bash

Значения кодов

Последнее обновление: 21 Апреля 2021 в 13:56

Источник

Подозрительно: массовые смс с кодами активации от разных сервисов

С десятка номеров пришли однотипные смс, одно за другим — «Ваш код подтверждения…»:

Некоторые сообщения продублировались утром и вечером. Что это может быть?

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

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

Обычная шутка

Начну с самого безобидного. Кто-то из знакомых, знающих ваш номер, решил ради шутки завалить ваш телефон сообщениями. Это делают с помощью программ, которые называются « смс-бомберы », или « смс-флудеры ». Не знаю, почему некоторые считают это смешным, но шутка достаточно популярная.

Как защититься. Если не планируете пользоваться сервисами, от которых пришли сообщения, просто заблокируйте имена отправителей.

Самозащита от мошенников

Создание баз номеров

Другая возможная цель такого скрипта — сбор информации. Скрипт пытается восстановить пароль на разных сервисах. Если процесс запустился, аккаунт с таким телефонным номером существует. Его вносят в базу номеров.

Использовать базу могут как угодно. Например, статистику о владельцах дисконтных карт одной торговой сети передадут в другую — и вы начнете получать от них уведомления об акциях и скидках. Или через некоторое время вам позвонит «сотрудник банка» и попытается выманить данные карты.

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

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

Попытка регистрации с подбором кода

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

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

Чем длиннее код, тем сложнее это сделать. Например, если код состоит из четырех цифр, существует 10 тысяч разных вариантов, а если из шести — вариантов уже миллион.

Скрипт можно научить проверять все эти варианты и автоматически вводить коды проверки один за другим — от 000000 до 999999. Здесь все зависит от защиты сайта: ограничивает ли он количество попыток, если ограничивает, то сколько их. И можно ли повторить процедуру с тем же номером через какое-то время.

Чем больше попыток дает сайт, тем выше вероятность, что скрипт успеет подобрать код и подтвердить «вашу» учетную запись без доступа к телефону и тексту смс. Например, в 2017 году на «Хабре» писали про угон аккаунтов одного каршеринга.

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

Я не стал перезапускать скрипт. Но даже за одну попытку вероятность подбора — 100 к 1 000 000, то есть 0,01%. Если перебрать 10 тысяч номеров, один из них удастся подтвердить. А если длина кода всего четыре символа, то при тех же условиях хватит ста номеров, чтобы подобрать код к одному из них и получить доступ к подтвержденному аккаунту. После этого можно рассылать с него спам от чужого имени.

Анна, вы написали, что сообщения приходили с определенными интервалами, утром и вечером. Это увеличивает вероятность того, что речь идет о подборе кода. Мошенник подождал предложенное сайтом время и снова запустил свой скрипт. Возможно, пытались взломать ваши аккаунты или зарегистрировать новые на ваш номер телефона.

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

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

Утечка паролей

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

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

Дальше код подтверждения попытаются подобрать по уже описанной схеме.

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

Маскировка важного смс

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

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

Если увидели что-то подозрительное, пишите. Возможно, кто-то пытается украсть ваши деньги.

Источник