смс аутентификация что это
Чем плоха СМС-аутентификация и как защититься от угона SIM-карты
Привет, Хабр! В прошлой статье мы затронули тему, что аутентификация по СМС – не самый лучший способ многофакторной аутентификации. Такой способ используют многие веб-сервисы: соцсети, почтовые клиенты, платежные системы. Вдобавок номер телефона используется в качестве логина: для регистрации ВКонтакте, в Telegram и так далее.
Если SIM-карту угонят, а СМС перехватят, последствия будут плачевны. Многие пользователи переписываются в мессенджерах с коллегами и партнерами, поэтому под угрозой окажутся не только личные данные, но и корпоративные. Если в вашей компании не используется корпоративная инфраструктура для общения, то незащищенные аккаунты сотрудников ставят под угрозу бизнес. Так что стоит позаботиться о безопасности заранее.
В этой статье возьмем несколько популярных сервисов и заменим СМС-аутентификацию на более безопасные способы. Заодно разберемся, как дополнительно защитить аккаунты от угона и спать спокойно.
На статью нас вдохновил лонгрид MyCrypto, посвященный защите от SIM-джекинга (SimJacking). Мы изучили их рекомендации и составили актуальный список для России.
Зачем избавляться от аутентификации по СМС
Злоумышленники могут получить СМС и зайти в чужой аккаунт сразу несколькими способами:
По каким признакам ясно, что симку угнали:
Как предупредить угон SIM-карты
Что делать, если все-таки угнали
Если SIM-карту уже угнали, у вас будет не более суток на блокировку. Поэтому нужно держать под рукой сценарий быстрой блокировки:
Как избавиться от СМС-аутентификации и защитить аккаунты
Наша общая рекомендация – откажитесь от СМС-аутентификации везде, где можно. Посмотрим, как это сделать для популярных веб-сервисов.
Сначала рассмотрим те, где используется СМС-аутентификация. А потом защитим те, где сам сервис привязан к номеру телефона.
Google-аккаунт
Яндекс
В Яндекс-аккаунте нет возможности включить двухфакторную аутентификацию без привязки номера. Поэтому мы будем использовать «секретный номер» и включать дополнительные факторы в других местах.
Теперь теми же способами защитите ВСЕ сервисы, которые могут использовать СМС-аутентификацию.
По возможности замените ее или привяжите к «секретному номеру» и добавьте вход по отпечатку пальца.
Telegram
Аккаунт мессенджера привязан к номеру телефона, поэтому, помимо двухфакторной аутентификации, настроим дополнительную защиту.
Все эти меры полностью не защитят от угона SIM-карт, но не позволят отдать мошенникам в руки джекпот. Если пользователи ведут удаленную работу с использованием личных девайсов и общедоступных веб-сервисов, это обезопасит и личные данные, и данные коллег.
Организация аутентификации по СМС по примеру 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.
Заключение
Вышеописанный подход позволит вам в рамках вашего стека технологий реализовать указанную задачу. Если вас есть соображения по этому подходу или альтернативные подходы, то прошу поделиться в комментариях. Аналогичная просьба, если у вас есть примеры документации к безопасным
Двухфакторная аутентификация: что это и зачем оно нужно?
Мы решили посвятить двухфакторной аутентификации отдельную статью и рассказать о том, что это такое, как она работает и почему ее стоит использовать.
Двухфакторная аутентификация — тема, которой мы так или иначе касаемся во многих наших постах. В прошлом году мы даже записали на эту тему целый подкаст. Однако ввиду возрастающего количества разных сервисов и все чаще случающихся атак на пользовательские аккаунты (как, например, перехваты контроля над учетными записями iCloud) мы решили посвятить этому виду аутентификации отдельную статью и рассказать о том, что это такое, как она работает и почему ее стоит использовать везде, где это возможно.
Что такое двухфакторная аутентификация?
Двухфакторная аутентификация — это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. На практике это обычно выглядит так: первый рубеж — это логин и пароль, второй — специальный код, приходящий по SMS или электронной почте. Реже второй «слой» защиты запрашивает специальный USB-ключ или биометрические данные пользователя. В общем, суть подхода очень проста: чтобы куда-то попасть, нужно дважды подтвердить тот факт, что вы — это вы, причем при помощи двух «ключей», одним из которых вы владеете, а другой держите в памяти.
Впрочем, двухфакторная защита не панацея от угона аккаунта, но достаточно надежный барьер, серьезно усложняющий злоумышленникам доступ к чужим данным и в какой-то степени нивелирующий недостатки классической парольной защиты. Ведь у паролей, на которых основано подавляющее большинство авторизационных механизмов в Интернете, есть неизбежные недостатки, которые фактически являются продолжением достоинств: короткие и простые пароли легко запомнить, но так же легко подобрать, а длинные и сложные трудно взломать, но и запомнить непросто. По этой причине многие люди используют довольно тривиальные пароли, причем сразу во многих местах. Второй фактор в подобных случаях оказывается крайне полезен, поскольку, даже если пароль был скомпрометирован, злоумышленнику придется или раздобыть мобильник жертвы, или угнать ее почтовый ящик.
Несмотря на многочисленные попытки современного человечества заменить пароли чем-то поинтереснее, полностью избавиться от этой привычной всем парадигмы оказалось не так просто, так что двухфакторную аутентификацию можно считать одним из самых надежных механизмов защиты на сегодняшний день. Кстати, этот метод удобен еще и тем, что способен предупреждать хозяина аккаунта о попытке взлома: если на ваш телефон или почту вдруг приходит сообщение с одноразовым кодом при том, что вы никаких попыток логина не предпринимали, значит, вас пытаются взломать — самое время менять оказавшийся ненадежным пароль!
Где можно включить двухфакторную аутентификацию?
Ответом на этот вопрос может служить простое правило: если используемый вами сервис содержит важные для вас данные и позволяет включить двухфакторную аутентификацию, активируйте ее не раздумывая! Вот, скажем, какой-нибудь Pinterest. Ну, не знаю… Если бы у меня был аккаунт в этом сервисе, я бы вряд ли захотел каждый раз проходить долгую процедуру двухслойной авторизации. А вот интернет-банкинг, аккаунты в соцсетях, учетка в iCloud, почтовые ящики и особенно ваши служебные учетные записи — все это однозначно стоит защитить двухфакторной аутентификацией. Сервисы Google, Apple и все основные социальные сети позволяют это сделать в настройках без особого труда.
Двухфакторная аутентификация — один из лучших методов защиты ваших аккаунтов #security
К слову, если у вас есть свой сайт, скажем, на базе WordPress или другой подобной платформе, включить в настройках двухфакторную защиту тоже не будет лишним. В общем, повторюсь: если аккаунт и его содержимое вам дороги, не игнорируйте возможность усилить защиту.
Какие еще существуют виды двухфакторной аутентификации?
Выше я уже упомянул рассылку специального кода в виде SMS и email-сообщений и USB-ключи и смарт-карты, используемые преимущественно для доступа к некоторым видам интернет-ресурсов и VPN-сетям. Кроме того, существуют еще генераторы кодов (в виде брелока с кнопкой и небольшим экранчиком), технология SecureID и некоторые другие специфические методы, характерные в основном для корпоративного сектора. Есть и менее современные интерпретации: например, так называемые TAN-пароли (TAN, Transaction Authentication Number — аутентификационный номер транзакции). Возможно, вы даже сталкивались с ними, если были клиентом какого-нибудь не самого прогрессивного банка: при подключении интернет-банкинга клиенту выдавалась бумажка с заранее сформированным списком одноразовых паролей, которые вводятся один за другим при каждом входе в систему и/или совершении транзакции. Кстати, ваша банковская карта и PIN тоже формируют систему двухфакторной аутентификации: карточка — «ключ», которым вы владеете, а PIN-код к ней — «ключ», который вы запоминаете.
Как я уже упомянул выше, существует и биометрический способ идентификации пользователя, который часто выступает в роли вторичного фактора защиты: одни системы подразумевают сканирование отпечатка пальца, другие определяют человека по глазам, есть даже те, которые ориентируются по «рисунку» сердцебиения. Но пока это все довольно экзотические методы, хотя и куда более популярные, чем, скажем, электромагнитные татуировки, которые по примеру радиочипов могут служить вторичным фактором аутентификации пользователя. Я бы от такой не отказался 🙂
Аутентификация по 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. Если нужный вам сервис позволяет ими воспользоваться, попробуйте отказаться от кодов из сообщений — постарайтесь обезопасить свои данные как можно раньше.
Коды в SMS небезопасны — рекомендуем пользоваться другими вариантами двухфакторной аутентификации
Почему SMS — не лучший выбор для двухфакторной аутентификации, и какие существуют альтернативы.
За последние пару лет идея двухфакторной аутентификации, о которой так долго говорили гики, сильно продвинулась в массы. Однако до сих пор в большинстве случаев речь идет о двухфакторной аутентификации при помощи одноразовых паролей, приходящих в SMS. А это, к сожалению, не очень-то надежный вариант. Вот что может пойти не так:
Надо заметить, что даже самый трудоемкий и высокотехнологичный из перечисленных методов перехвата пароля в SMS — с помощью взлома протокола SS7 — уже был использован на практике. Так что речь не о теоретической возможности возникновения неприятностей, а о вполне практической угрозе.
В общем, пароли в SMS — это не очень-то безопасно, а иногда даже и очень небезопасно. Поэтому есть смысл озаботиться поиском альтернативных вариантов двухэтапной аутентификации, о чем мы сегодня и поговорим.
Одноразовые коды в файле или на бумажке
Наиболее простая замена одноразовым паролям, присылаемым в SMS, — это те же самые одноразовые пароли, но заготовленные заранее. Это не самый плохой вариант, особенно для тех сервисов, в которых вам надо авторизовываться сравнительно редко. Собственно, даже для того же «Фейсбука» этот метод вполне может подойти, особенно в качестве резервного способа входа.
Работает это очень просто: по запросу сервис генерирует и показывает на экране десяток одноразовых кодов, которые в дальнейшем могут быть использованы для подтверждения входа в него. Дальше вы просто распечатываете или переписываете эти коды на бумагу и кладете в сейф. Или, что еще проще, сохраняете в зашифрованных записях в менеджере паролей.
В общем, не так важно, будете ли вы хранить эти коды на теплой ламповой бумаге или в бездушном цифровом виде — важно сохранить их так, чтобы они а) не потерялись и б) не могли быть украдены.
Приложения для двухфакторной аутентификации
У единожды сгенерированного набора одноразовых кодов есть один недостаток: рано или поздно он закончится, и вполне может так получиться, что вы останетесь без кода в самый неподходящий момент. Поэтому есть способ лучше: можно генерировать одноразовые коды на лету с помощью небольшого и, как правило, очень простого приложения — аутентификатора.
Как работают приложения-аутентификаторы
Работают приложения для двухфакторной аутентификации очень просто. Вот что придется сделать:
Коды создаются на основе ключа, который известен только вам и серверу, а также текущего времени, округленного до 30 секунд. Поскольку обе составляющие одинаковы и у вас, и у сервиса, коды генерируются синхронно. Этот алгоритм называется OATH TOTP (Time-based One-time Password), и в подавляющем большинстве случаев используется именно он.
Также существует альтернатива — алгоритм OATH HOTP (HMAC-based One-time Password). В нем вместо текущего времени используется счетчик, увеличивающийся на 1 при каждом новом созданном коде. Но этот алгоритм редко встречается в реальности, поскольку при его использовании гораздо сложнее обеспечить синхронное создание кодов на стороне сервиса и приложения. Проще говоря, есть немалый риск, что в один не очень прекрасный момент счетчик собьется и ваш одноразовый пароль не сработает.
Так что можно считать OATH TOTP де-факто индустриальным стандартом (хотя формально это даже не стандарт, на чем создатели этого алгоритма очень настаивают в его описании).
Совместимость приложений для двухфакторной аутентификации и сервисов
Подавляющее большинство приложений для двухфакторной аутентификации работает по одному и тому же алгоритму, так что для всех сервисов, которые поддерживают аутентификаторы, можно использовать любое из них — какое вам больше нравится.
Как и в любом добротном правиле, в этом тоже есть определенное количество исключений. Некоторые сервисы по каким-то причинам, ведомым только им одним, предпочитают делать свои собственные приложения для двухфакторной аутентификации, которые работают только с ними. Более того, сами сервисы не работают ни с какими другими приложениями, кроме своих собственных.
Особенно это распространено среди крупных издателей компьютерных игр — например, существуют несовместимые со сторонними сервисами приложения Blizzard Authenticator, Steam Mobile с встроенным аутентификатором Steam Guard, Wargaming Auth и так далее. Для этих сервисов придется ставить именно эти приложения.
Также по этому странному пути пошла Adobe, разработавшая Adobe Authenticator, который работает только с аккаунтами AdobeID. Но при этом вы можете использовать для защиты AdobeID и другие аутентификаторы, так что вообще непонятно, ради чего было городить огород.
Так или иначе, большинство нормальных ИТ-компаний не ограничивает пользователей в выборе 2FA-приложения. И даже если по каким-то соображениям им хочется контролировать этот процесс и создать свое приложение, то чаще всего они позволяют защищать с его помощью не только «свои» аккаунты, но и учетные записи сторонних сервисов.
Поэтому просто выбирайте приложение-аутентификатор, которое вам больше нравится по набору дополнительных функций — оно будет работать с большинством сервисов, которые вообще поддерживают 2FA-приложения.
Лучшие приложения для двухфакторной аутентификации
Выбор 2FA-приложений на удивление велик: поиск по запросу «authenticator» в Google Play или Apple App Store выдает не один десяток результатов. Мы не советуем устанавливать первое попавшееся приложение — это может быть небезопасно, ведь, по сути, вы собираетесь доверить ему ключи от своих аккаунтов (оно не будет знать ваши пароли, конечно, но ведь 2FA вы добавляете именно потому, что пароли имеют свойство утекать). В общем, стоит выбирать из приложений, созданных крупными и уважаемыми разработчиками.
Несмотря на то что базовая функция у всех этих приложений одна и та же — создание одноразовых кодов по одному и тому же алгоритму, некоторые аутентификаторы обладают дополнительными функциями или особенностями интерфейса, которые могут показаться вам удобными. Перечислим несколько самых интересных вариантов.
1. Google Authenticator
Поддерживаемые платформы: Android, iOS
Как отмечают буквально все публикации, Google Authenticator — это самое простое в использовании из всех существующих приложений для двухфакторной аутентификации. У него даже настроек нет. Все, что можно сделать, — это добавить новый токен (так называется генератор кодов для отдельного аккаунта) или удалить один из имеющихся. А чтобы скопировать код в буфер обмена, достаточно коснуться его пальцем на сенсорном экране смартфона или планшета. Все!
Однако у такой простоты есть и недостаток: если вам что-то не нравится в интерфейсе или хочется от аутентификатора чего-то большего — придется устанавливать другое приложение.
+ Очень просто использовать.
2. Duo Mobile
Поддерживаемые платформы: Android, iOS
Duo Mobile также крайне прост в использовании, минималистичен и лишен дополнительных настроек. По сравнению с Google Authenticator у него есть одно преимущество: по умолчанию Duo Mobile скрывает коды — чтобы увидеть код, надо нажать на конкретный токен. Если вы, как и я, испытываете дискомфорт каждый раз, когда открываете аутентификатор и показываете всем окружающим кучу кодов от всех своих аккаунтов сразу, то вам эта особенность Duo Mobile наверняка понравится.
+ По умолчанию скрывает коды.
3. Microsoft Authenticator
Поддерживаемые платформы: Android, iOS
В Microsoft тоже не стали усложнять и сделали свой аутентификатор на вид очень минималистичным. Но при этом Microsoft Authenticator заметно функциональнее, чем Google Authenticator. Во-первых, хоть по умолчанию все коды показываются, но каждый из токенов можно отдельно настроить так, чтобы при запуске приложения код был скрыт.
Во-вторых, Microsoft Authenticator упрощает вход в аккаунты Microsoft. В этом случае после ввода пароля достаточно будет нажать в приложении кнопку подтверждения входа — и все, можно даже не вводить одноразовый код.
+ Можно настроить, чтобы коды скрывались.
+ Дополнительные возможности для входа в аккаунты Microsoft.
4. FreeOTP
Поддерживаемые платформы: Android, iOS
Есть четыре причины, по которым вам может понравиться этот аутентификатор, разработанный Red Hat. Во-первых, это ваш выбор, если вы любите программное обеспечение с открытым кодом. Во-вторых, это самое маленькое приложение из всех рассматриваемых — версия для iOS занимает всего 750 Кбайт. Для сравнения: минималистичный Google Authenticator занимает почти 14 Мбайт, а приложение Authy, о котором мы поговорим ниже, — аж 44 Мбайта.
В-третьих, по умолчанию приложение скрывает коды и показывает их только после касания. Наконец, в-четвертых, FreeOTP позволяет максимально гибко конфигурировать токены вручную, если вам это зачем-нибудь нужно. Разумеется, обычный способ создания токена с помощью сканирования QR-кода тоже поддерживается.
+ По умолчанию скрывает коды.
+ Приложение занимает всего 700 Кбайт.
+ Открытый код.
+ Максимум настроек при создании токена вручную.
5. Authy
Самое навороченное из приложений для двухфакторной аутентификации, основным достоинством которого является то, что все токены хранятся в облаке. Это позволяет получить доступ к токенам с любого из ваших устройств. Заодно это упрощает переезд на новые устройства — не придется заново активировать 2FA в каждом сервисе, можно продолжить пользоваться существующими токенами.
В облаке токены зашифрованы ключом, который создается на основе заданного пользователем пароля, — то есть данные хранятся безопасно, и украсть их будет нелегко. Также можно установить ПИН-код на вход в приложение — или защитить его отпечатком пальца, если ваш смартфон оснащен соответствующим сканером.
Основной недостаток Authy состоит в том, что приложение с ходу требует завести аккаунт, привязанный к вашему телефонному номеру, — без этого просто не получится начать с ним работать.
+ Токены хранятся в облаке, что позволяет использовать их на всех своих устройствах.
+ По той же причине очень удобно переезжать на новое устройство.
+ Вход в приложение защищен PIN-кодом или отпечатком пальца.
+ На экране показывается код только для последнего использованного токена.
+ В отличие от остальных приложений, поддерживает не только Android и iOS, но и Windows, macOS и Chrome.
− Требуется зарегистрироваться в Authy, используя номер телефона, — без этого приложение не работает.
6. «Яндекс.Ключ»
Поддерживаемые платформы: Android, iOS
На мой взгляд, по концепции «Яндекс.Ключ» — это самое удачное из существующих приложений для двухфакторной аутентификации. С одной стороны, оно не требует с ходу регистрироваться — можно начать им пользоваться с той же легкостью, как и Google Authenticator. С другой стороны, в нем есть несколько дополнительных возможностей, которые открываются тем, кто не поленится зайти в настройки.
Во-первых, «Яндекс.Ключ» можно «запереть» на PIN-код или отпечаток пальца. Во-вторых, можно создать в облаке «Яндекса» резервную копию токенов, защищенную паролем (а вот на этом этапе уже придется указать номер телефона), и восстановить ее на любом из используемых вами устройств. Точно так же можно будет перенести токены на новое устройство, когда понадобится переезжать.
Получается, что «Яндекс.Ключ» сочетает в себе простоту Google Authenticator и расширенную функциональность Authy — в зависимости от того, что вы предпочитаете. Единственный недостаток приложения — не вполне удобный для использования с большим количеством токенов интерфейс.
+ Минимализм на старте, расширенная функциональность доступна через настройки.
+ Создание резервных копий токенов в облаке для использования на нескольких устройствах и переезда на новые.
+ Вход в приложение защищен PIN-кодом или отпечатком пальца.
+ На экране показывается код только для последнего использованного токена.
+ Заменяет постоянный пароль к аккаунту «Яндекса».
− При большом количестве токенов не очень удобно искать нужный.
«Железные» аутентификаторы FIDO U2F: YubiKey и все-все-все
Если приложение, генерирующее одноразовые коды, кажется вам слишком эфемерным способом защитить свои аккаунты, и хочется чего-то более постоянного, надежного и материального — буквально запереть аккаунт на ключ и положить его в карман, — то у меня есть для вас хорошая новость: такой вариант также существует. Это аппаратные токены стандарта U2F (Universal 2nd Factor), созданного FIDO Alliance.
Как работают токены FIDO U2F
Аппаратные U2F-токены очень полюбились специалистам по безопасности — в первую очередь потому, что с точки зрения пользователя они работают очень просто. Для начала работы достаточно подключить U2F-токен к вашему устройству и зарегистрировать его в совместимом сервисе, причем делается это буквально в пару кликов.
Впоследствии при необходимости подтвердить вход в этот сервис нужно будет подключить U2F-токен к тому устройству, с которого вы входите, и нажать на токене кнопку (в некоторых устройствах — ввести PIN или приложить палец к сканеру). Все — никаких сложных настроек, ввода длинных последовательностей случайных символов и прочих танцев с бубном, которые обычно все себе представляют при упоминании слова «криптография».
Вставьте ключ и нажмите кнопку — и это действительно все
При этом «под капотом» все устроено очень умно и криптографически надежно: при регистрации токена на сервисе создается пара криптографических ключей — приватный и публичный. Публичный сохраняется на сервере, а приватный хранится в защищенном хранилище Secure Element, которое является сердцем U2F-токена, — и этот ключ никогда не покидает устройство.
Приватный ключ используется для того, чтобы зашифровать подтверждение входа, которое передается на сервер и может быть расшифровано с помощью публичного ключа. Если кто-то от вашего имени попытается передать подтверждение входа, зашифрованное неправильным приватным ключом, то при расшифровке с помощью известного сервису публичного ключа вместо подтверждения получится бессмыслица, и сервис не пустит его в аккаунт.
Какими бывают U2F-устройства
Наиболее известный и распространенный пример U2F — это «ключи» YubiKey, которые производит компания Yubico. Собственно, она и стояла у истоков этого стандарта, но предпочла сделать его открытым, для чего и был создан FIDO Alliance. А поскольку стандарт открытый, вы не ограничены в выборе: U2F-совместимые устройства производят и продают разные компании — в онлайн-магазинах можно найти множество разнообразных моделей.
YubiKey — вероятно, самые популярные U2F-токены
Например, Google недавно представила свой комплект аппаратных аутентификаторов Google Titan Security Keys. На самом деле это ключи производства Feitian Technologies (второй по популярности производитель U2F-токенов после Yubico), для которых в Google написали собственную прошивку.
Разумеется, все аппаратные аутентификаторы, совместимые со стандартом U2F, будут с одинаковым успехом работать со всеми сервисами, которые также с этим стандартом совместимы. Однако у разных моделей есть несколько важных различий, и самое важное из них — это интерфейсы, которыми оборудован «ключ». От этого напрямую зависит, с какими устройствами он сможет работать:
USB — для подключения к компьютерам (Windows, Mac или Linux — неважно, «ключи» работают без установки каких-либо драйверов). Помимо обычного USB-A бывают «ключи» с USB-C.
NFC — необходим для использования со смартфонами и планшетами на Android.
Bluetooth — понадобится на тех мобильных устройствах, в которых нет NFC. К примеру, аутентификатор с Bluetooth все еще нужен владельцам iPhone: несмотря на то, что в iOS уже разрешили приложениям использовать NFC (до 2018 года это было позволено только Apple Pay), разработчики большинства совместимых с U2F приложений еще не воспользовались этой возможностью. У Bluetooth-аутентификаторов есть пара минусов: во-первых, их нужно заряжать, а во-вторых, их подключение занимает гораздо больше времени.
Что же выбрать: SMS, приложение или YubiKey?
Универсального ответа на этот вопрос не существует — для разных сервисов можно использовать разные варианты двухфакторной аутентификации в различных сочетаниях. Например, наиболее важные аккаунты (скажем, вашу основную почту, к которой привязаны остальные учетные записи) стоит защитить по максимуму — запереть на «железный» U2F-токен и запретить любые другие опции 2FA. Так можно быть уверенным, что никто и никогда не получит доступ к аккаунту без этого токена.
Хороший вариант — привязать к аккаунту два «ключа», как это делается с ключами от автомобиля: один всегда с собой, а другой лежит в надежном месте — на случай, если первый потеряется. При этом «ключи» могут быть разного типа: скажем, приложение-аутентификатор на смартфоне в качестве основного и U2F-токен или листочек с одноразовыми паролями, лежащий в сейфе, в качестве резервного средства.
Так или иначе, главный совет — по возможности избегать использования одноразовых паролей в SMS. Правда, получится это не всегда: например, финансовые сервисы в силу своей консервативности продолжают использовать SMS и крайне редко позволяют пользоваться чем-либо еще.