Sms аутентификация что это
Authentify смс что это? Почему приходят сообщения аутентификации?
Многим пользователям стали приходить сообщения от Authentify. Обычно их отправляет сервис аутентификации с текстом «используйте как код безопасности» и набором цифр. Он отвечает за авторизацию пользователей на сайтах, банковских клиентах, социальных сетях и электронной почте. Ниже мы расскажем, что значит смс от Authentify, как защитить себя и свои данные, а так же что делать при получении такого сообщения. Бывает что сообщения приходят просто так, даже если вы не делали привязку Play Маркета к своей карте, давайте разбираться.
Что такое смс от Authentify?
Сообщение от сервиса аутентификации обычно приходит при попытке входа или сброса пароля к какому-нибудь сайту, где нужны ваш логин и пароль.
СМС от Authentify – это сообщение, содержащее текстовую информацию и код подтверждения. Сама информация различного характера, а вот код может быть использован для входа в ваши аккаунты банковских приложений, почты, социальных сетей. И если банковские счета и карты есть не у всех, то электронная почта нужна при любой регистрации на сайте. Простыми словами взломав вашу почту, злоумышленники смогут восстановить пароли к любой сети, сайту и сервису на котором вы регистрировались.
Вот примеры текстов, которые приходят пользователям:
Authentify смс что это, стоит ли доверять?
Откуда мой номер в базе?
Как было сказано выше, номер мог засветиться, если было скачано вирусное приложение содержащее троян. Но в большинстве случаев ваш мобильный уже находится в открытом доступе, как это происходит?
Получить ваш номер дело нехитрое, достаточно самим указать его на одной из страниц в сети Интернет.
А если я сам регистрируюсь?
Если вы получили смску в процессе регистрации на каком-нибудь сайте, где вводили номер телефона – мог придти код подтверждения, который не несёт никакой угрозы. В этом случае сообщение угрозы не представляет. Если такая рассылка приходит по несколько раз в день, тут надо защитить свои данные, об этом ниже.
Как защитить свои данные?
Первое правило вы должны знать как дважды два: при получении рассылки содержащей код: никому, ни при каких обстоятельствах не говорим и не пересылаем его. Даже если вам позвонят и представятся работниками поддержки сайта или банковскими сотрудниками. Второе – обязательно устанавливаем двухфакторную аутентификацию там, где это возможно: на сайтах электронной почты и в социальных сетях, где больше всего проводите времени. Делается это в настройках.
Двухфакторная аутентификация – способ защиты входа на сайт. После ввода логина и пароля к вашим страницам и личному кабинету, вам потребуется так же ввести код полученный в смске на ваш номер телефона. На сегодня это самый оптимальный метод защиты, главное помнить про первое правило.
В Play Маркет находим и устанавливаем Kaspersky Internet Security: Антивирус и Защита или Антивирус Dr.Web Light. Это поможет найти и удалить опасные приложения и вирусы со смартфона, если таковые имеются.
Блокируем рассылку
Если сообщения приходят по несколько раз в день, следует не раздумывая добавить номер, с которого ведется рассылка в черный список. Для этого открываем полученное сообщение и кликаем на имя отправителя Authentify. Откроется окошко с небольшой информацией и номером(если он не скрыт, тогда будет написано «Неизвестный номер»). Ниже нажимаем кнопку «Заблокировать».
Заключение
Сообщения от Authentify это очередная попытка спамеров засыпать ваш телефон ненужной информацией или происки злоумышленников для получения доступа к вашим данным. А слова «используйте как код безопасности» наоборот подвергают опасности ваши данные. Простые советы выше помогут вам защитить вашу информацию и аккаунты электронной почты и соцсетей. Напишите в комментариях полезной ли оказалась информация, так же можете писать примеры ваших сообщений, поступивших на ваши смартфоны.
Евгений Загорский
IT специалист. Автор информационных статей на тему Андроид смартфонов и IOS смартфонов. Эксперт в области решения проблем с компьютерами и программами: установка, настройка, обзоры, советы по безопасности ваших устройств. В свободное время занимается дизайном и разработкой сайтов.
Чем плоха СМС-аутентификация и как защититься от угона SIM-карты
Привет, Хабр! В прошлой статье мы затронули тему, что аутентификация по СМС – не самый лучший способ многофакторной аутентификации. Такой способ используют многие веб-сервисы: соцсети, почтовые клиенты, платежные системы. Вдобавок номер телефона используется в качестве логина: для регистрации ВКонтакте, в Telegram и так далее.
Если SIM-карту угонят, а СМС перехватят, последствия будут плачевны. Многие пользователи переписываются в мессенджерах с коллегами и партнерами, поэтому под угрозой окажутся не только личные данные, но и корпоративные. Если в вашей компании не используется корпоративная инфраструктура для общения, то незащищенные аккаунты сотрудников ставят под угрозу бизнес. Так что стоит позаботиться о безопасности заранее.
В этой статье возьмем несколько популярных сервисов и заменим СМС-аутентификацию на более безопасные способы. Заодно разберемся, как дополнительно защитить аккаунты от угона и спать спокойно.
На статью нас вдохновил лонгрид MyCrypto, посвященный защите от SIM-джекинга (SimJacking). Мы изучили их рекомендации и составили актуальный список для России.
Зачем избавляться от аутентификации по СМС
Злоумышленники могут получить СМС и зайти в чужой аккаунт сразу несколькими способами:
По каким признакам ясно, что симку угнали:
Как предупредить угон SIM-карты
Что делать, если все-таки угнали
Если SIM-карту уже угнали, у вас будет не более суток на блокировку. Поэтому нужно держать под рукой сценарий быстрой блокировки:
Как избавиться от СМС-аутентификации и защитить аккаунты
Наша общая рекомендация – откажитесь от СМС-аутентификации везде, где можно. Посмотрим, как это сделать для популярных веб-сервисов.
Сначала рассмотрим те, где используется СМС-аутентификация. А потом защитим те, где сам сервис привязан к номеру телефона.
Google-аккаунт
Яндекс
В Яндекс-аккаунте нет возможности включить двухфакторную аутентификацию без привязки номера. Поэтому мы будем использовать «секретный номер» и включать дополнительные факторы в других местах.
Теперь теми же способами защитите ВСЕ сервисы, которые могут использовать СМС-аутентификацию.
По возможности замените ее или привяжите к «секретному номеру» и добавьте вход по отпечатку пальца.
Telegram
Аккаунт мессенджера привязан к номеру телефона, поэтому, помимо двухфакторной аутентификации, настроим дополнительную защиту.
Все эти меры полностью не защитят от угона SIM-карт, но не позволят отдать мошенникам в руки джекпот. Если пользователи ведут удаленную работу с использованием личных девайсов и общедоступных веб-сервисов, это обезопасит и личные данные, и данные коллег.
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Аутентификация по SMS — иллюзия безопасности
На протяжении многих лет главным способом идентификации пользователя являлся ввод логина и пароля. Если данные или хеши совпали с эталонными, доступ к информации предоставляется, в противном случае можно позволить пользователю ввести логин и пароль повторно. Все чаще используется аутентификация со вторым шагом — введением кода из SMS. Но этот метод аутентификации не всегда безопасен. Почему?
Почему одного шага недостаточно?
Как нетрудно догадаться, при идентификации по логину и паролю степень защищенности ваших данных напрямую зависит от сложности пароля. Разумеется, можно придумать свою систему запоминания паролей, которая позволит «хранить» в голове сложные пароли для различных программ и сайтов. Можно пользоваться и специализированными менеджерами паролей или создать свою базу данных, защищенную мастер-паролем. В этих случаях вам достаточно запомнить только один пароль от программы или своей базы.
Но, увы, многие пользователи не слишком внимательно относятся к безопасности своих данных и используют повторяющиеся несложные пароли на разных сайтах — их легко подобрать.
Если пароль будет скомпрометирован, но аккаунт при этом защищен двухфакторной аутентификацией, злоумышленнику придется получить и доступ к устройству, на которое будет отправлен код из SMS (если используется самая распространенная схема защиты). Это, разумеется, тоже возможно, но получить доступ к устройству гораздо сложнее, чем украсть пароль.
SMS под угрозой
Однако специалисты по сетевой безопасности считают коды из SMS недостаточно безопасным способом аутентификации. Во-первых, сообщение с кодом может быть перехвачено вредоносным ПО, установленным на смартфон жертвы. Во-вторых, можно подкупить сотрудника салона сотовой связи и выпустить новую сим-карту с номером телефона жертвы: такие случаи уже бывали в разных странах. Наконец, код из SMS можно просто подсмотреть и передать злоумышленнику.
Но главное — протокол сигнальной системы SS7, который используется для передачи сообщений в мобильных сетях, имеет серьезные уязвимости. Еще в 2014 году была опубликована схема, иллюстрирующая перехват SMS в сотовых сетях. Атака основана на регистрации жертвы в зоне действия поддельного центра мобильной коммутации. Идентификационный номер абонента злоумышленник может получить специально подготовленным запросом: выполнить его как раз и позволяет уязвимость в SS7. Как только жертва регистрируется в сети поддельного оператора, он перестает получать звонки и сообщения. Данные при этом поступают злоумышленникам, подготовившим атаку. Способ атаки, конечно, непростой, но уже известно, что им пользовались и хакеры, и спецслужбы разных стран мира, перехватывая SMS-коды от Gmail, Telegram, Facebook, банков.
В 2016 году Национальный институт стандартов и технологий США официально признал аутентификацию с помощью SMS небезопасной. Специалисты указали, что в будущих версиях руководств по цифровой аутентификации этот способ не будет включаться в число рекомендуемых.
Кроме того, получение кодов в сообщениях может даже ухудшить безопасность пользовательских данных. Зачастую владельцы данных излишне полагаются на SMS-коды и устанавливают достаточно простые пароли, что делает их учетные записи менее защищенными.
Что использовать вместо SMS?
На данный момент существует несколько альтернатив, которые можно использовать вместо SMS-кодов. Самый простой — одноразовые коды, наподобие тех, которые умеют формировать банкоматы для входа в интернет-банк. Эти коды можно хранить в менеджерах паролей наподобие KeePass. Главное — чтобы коды не потерялись или не были украдены.
Также можно использовать приложения-аутентификаторы, такие как Google Authenticator, Яндекс.Ключ или FreeOTP. После установки приложения на смартфон надо войти в настройки аутентификации в нужном вам сервисе. Выбираем аутентификацию с помощью приложения — сервис должен показать нам QR-код, который сканируется установленным приложением. После успешного сканирования кода вы сможете войти в свой аккаунт. Чтобы данный способ сработал, необходимо, чтобы время на вашем устройстве и на сервере, где расположен нужный сайт, отличалось не более чем на 30 секунд.
Еще один альтернативный вариант аутентификации — это USB-ключ с записанным на нем цифровым сертификатом. Этот способ достаточно безопасен: для получения доступа к данным необходимо не только знать пароль (обычно сложный), но и владеть ключом. Хотя брелок с записанным ключом, увы, можно потерять или устройство может сломаться.
Наиболее безопасное на сегодняшний день решение для второго шага аутентификации — биометрическая аутентификация (как правило, по отпечатку пальца или сетчатке глаза). Данный способ уже используется для разблокировки многих смартфонов и ноутбуков, постепенно его начинают использовать и для работы с разнообразными сервисами.
К сожалению, аутентификацию по отпечатку пальца тоже нельзя назвать панацеей: многие сканеры отпечатков можно обмануть с помощью тонкого накладного отпечатка, выполненного из токопроводящего материала. Да и обладателя настоящего отпечатка можно напоить или «угостить» снотворным и получить доступ к его данным (увы, и подобные преступления не так уж редки).
Перечисленные альтернативные способы аутентификации зачастую могут быть гораздо более безопасны, чем отправка кодов в 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.
Заключение
Вышеописанный подход позволит вам в рамках вашего стека технологий реализовать указанную задачу. Если вас есть соображения по этому подходу или альтернативные подходы, то прошу поделиться в комментариях. Аналогичная просьба, если у вас есть примеры документации к безопасным