отправка кодов в телефонном номере

Отправка кодов в телефонном номере

стоимость
одного сообщения
с кодом

мониторинг доставки
в реальном времени

отправка кодов
на мобильные и
стационарные номера
с АОН

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

Чтобы передать код в телефонном номере, необходимо отправить абоненту специальное голосовое сообщение (voice) со словом code, по которому абоненту будет выполнен звонок со случайного номера из заданного пула. При получении звонка абонент может его сбросить или поднять трубку. При поднятии трубки система сама сбросит звонок. Последние 6 цифр номера, с которого пришел звонок, будут являться секретным кодом, его необходимо использовать абоненту для подтверждения операции в вашем сервисе. Также можно использовать более короткие коды из номера, указав количество цифр в инструкции для пользователей на вашем сайте.

Возможности

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

Описание и примеры отправки смотрите в разделе API Отправка кода в телефонном номере.

Тарифы

Тарификация звонков с кодами в телефонном номере будет соответствовать минимальной длине (5 секунд) голосового (voice) сообщения согласно установленному тарифному плану.

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

Источник

Интеграция с сервисом (API)

API позволяет рассылать сообщения через ваши проекты и сервисы по протоколам HTTP/HTTPS, SMTP и SMPP. Готовые библиотеки на разных языках программирования подключаются к вашему проекту и помогают отправлять сообщения из любого места с помощью одной команды.

Отправка кода в телефонном номере

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

Чтобы передать код в телефонном номере необходимо отправить абоненту специальное голосовое сообщение (звонок) со словом code. При получении звонка абонент может его сбросить или поднять трубку. При поднятии трубки система сама сбросит звонок. Последние 6 цифр номера, с которого пришел звонок, будут являться секретным кодом, его необходимо использовать абоненту для подтверждения операции. Также возможно использование более короткого кода из номера, указав количество цифр в инструкции для пользователей на своем сайте.

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

Формат запроса и ответ Сервера: https://smsc.ru/sys/send.php?login= &psw=

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

Источник

Верификация по СМС: есть ли альтернативы?

У верификации по СМС есть три существенных недостатка: это дорого (1,5 рубля за эсэмэску), в доставке часто происходят сбои, сообщение приходится ждать до 5 минут – не у всех на это хватает терпения. А еще пользователи могут банально не доверять сайту или приложению и отказываться от авторизации по СМС. Особенно если ваш продукт новый и никому не известен. С СМС-рассылками могут бороться и сами операторы связи. Так теряются трафик и клиенты. Однако есть несколько альтернатив верификации по СМС. Посмотрим, какие из них выгодны вам.

Пользователь должен позвонить на указанный номер телефона, его встречает АОН и регистрирует номер. У авторизации по исходящему звонку много минусов:

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

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

Пользователь указывает свой номер телефона, на этот номер поступает входящий звонок, пользователь его принимает, и робот диктует ему пароль. Это хороший способ реализации, дешевле, чем СМС, но дороже, чем Call Password. Стандартная стоимость доставки одного кода – около 0,49 рубля. Этот метод хорош тем, что обеспечивает доставку сообщения в течение 5–6 секунд, умеет фильтровать виртуальные номера (спам-боты) и принимать не только мобильные, но и городские номера.

У услуги есть три минуса:

Этот вариант подходит вам, если вы работаете в одном регионе и на 100 % уверены в доверии потенциальных клиентов.

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

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

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

В чем особенности услуги:

Это решение на данный момент – самое дешевое и безопасное для компании по сравнению с авторизацией СМС.

Эту технологию используют везде, где нужна авторизация. Например, чтобы зарегистрироваться на сайте и войти в личный кабинет, подтверждать заказы в интернет-магазине, подключаться к Wi-Fi в кафе или фитнес-клубе, делать переводы в банковском приложении. А также для двухфакторной аутентификации и восстановления паролей.

Источник

Доставка одноразовых кодов в голосовом сообщении при звонке на номер телефона

Надежней чем СМС

Гарантированная стабильная доставка кодов. Операторы не борются со входящими звонками, в отличие от СМС рассылок.

Эффективный фильтр «виртуальных номеров»

Вы получаете реальный номер клиента, по которому с ним можно созвониться. Для получения кода, клиент должен ответить на звонок и прослушать код. Роботы не пройдут!

Стоимость доставки одного кода от 0,36 руб. При этом вы не платите за коды, отправленные на «виртуальный номер», т.к. звонок на них не пройдет

Мы сделали всю работу по доставке кодов. Вам осталось добавить только небольшой скрипт на сайт, который будет обращаться к нашему сервису

Звонок клиенту придет с вашего номера

Клиент сразу получит ваш контакт и сможет перезвонить по нему

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

Прозрачные тарифы

Вы платите только за состоявшиеся звонки, когда клиент поднял трубку.

Пакет действует в течении 6 месяцев. После окончания пакета, отправка кодов будет тарифицироваться по стандартному тарифу.

NeoPhone

Предоставляем услуги связи с 2002 года.

Обслуживаем более 1 800 000 звонков ежемесячно.

Лицензированный оператор связи.

Прямые стыки с крупнейшими операторами. Собственый дата-центр.

Вам не придется полчаса выслушивать автоответчик, робота, или промежуточный call-центр.

68% наших клиентов рекомендуют нас своим друзьям. Тестируйте сами!

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

Так же виртуальная АТС NeoPhone отлично работает с различными CRM системами, все переговоры с клиентом будут записаны и автоматически привязаны к его контакту. Купить облачную АТС можно через сайт, просто подберите понравившийся номер, зарегистрируйтесь и начинайте принимать звонки. В NeoPhone предусмотрены разные варианты оплаты. По всем интересующим вопросам вы можете обратиться в нашу службу технической поддержки по телефону +7 (495) 946 946 0.

Источник

Организация аутентификации по СМС по примеру 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.

Заключение

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

Источник