Запросить СМС с кодом на номер, в ответ — токен для последующих действий.
Действие соответствует CREATE в CRUD.
POST /api/sms_authentications/
Параметры на вход:
phone
Параметры на выход:
token
Если всё прошло, как ожидается, возвращаем код состояния 200.
Если же нет, то есть одно разумное исключение (помимо стандартной 500 ошибки при проблемах на сервере и т.п. — некорректно указан телефон. В этом случае:
Подтвердить токен с помощью кода из СМС.
Действие соответствует UPDATE в CRUD.
PUT /api/sms_authentications/<token>/
Параметры на вход:
sms_code
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
Форсированная отправка кода повторно.
PUT /api/sms_authentications/<token>/resend
Аналогично. Если всё ок — код 200.
Если же нет, то варианты исключений:
Face id
Последнее новшество от Apple – аутентификация посредством распознавания лица. Если для отпечатков пальцев достаточно теоретически несложной алгоритмической обработки, то для распознавания лиц прибегают к идеям Розенблатта и строят нейросеть.
Конечно же, мощности нейросети в iPhone недостаточно для игры в шахматы или го, но со своей задачей она справляется. Телефон теперь может опознать своего хозяина визуально.
Эти последние новшества, как нетрудно представить, бесконечно радуют корпоративных офицеров безопасности и настолько же бесконечно раздражают конечных пользователей. Здесь, на передовом технологическом крае, сходятся щит и меч, добро и зло, и лёд, и пламя. Здесь куётся MFA.
Touchid/fingerprints
Широко известно, что человек обладает уникальными отпечатками пальцев. Кроме того, уникальными являются отпечатки носов и ушей, причём если пальцы – атрибут в основном сугубо человеческий, то носы есть и у домашних животных. На практике опознавание по отпечаткам носов используется для идентификации кошек, собак и коров.
Когда-нибудь, возможно, мы научим наши телефоны опознавать хозяина, просто взяв его в руку, но пока что технология сосредоточилась на дактилоскопии, закрепившейся в криминалистической практике ещё сто лет назад (то, что это очень удобно и для АНБ, мы оставим за рамками статьи).
Кроме того, что многие телефончики оснащены сканерами отпечатков пальцев и уже упоминавшимся PIN-кодом, ряд из них дополняется графическим ключом – то есть можно задать вместо цифровой комбинации некий кодовый рисунок, соединяя точки на экране в той или иной последовательности.
Блокчейн и китайские куры
После того, как биткоин и прочие криптовалюты произвели ажиотажный общественный резонанс, было бы странно, если бы лежащий в основе трансакций этих валют блокчейн не привлёк внимание разработчиков систем безопасности.
Как же можно задействовать цепочку блоков для аутентификации? Очень просто.
Применительно к человеку, сама по себе технология блокчейн уже сегодня работает в Эстонии как платформа для электронного гражданства; есть подобные попытки в Бразилии и Финляндии. А японская Sony скрестила MFA и блокчейн (U.S. patent 2022/0310653 A1*).
Что же касается других применений, то известно, что в Китае придумали посредством блокчейн отслеживать, что случалось в жизни кур, попадающих на стол особых ценителей высокой кухни.
Проектировщики будущего! Пожалуйста, постарайтесь, чтобы наши гаджеты узнавали своих хозяев не хуже собаки, при этом, по возможности, обходясь без собачьего корма, и чтобы их не нужно было слишком часто выгуливать.
Автор этих строк также выражает надежду на то, что его телефон лет через десять не удастся приманить и облапошить аппетитно пахнущей сосиской.
Изменения в api
В сущности требуется добавить три метода в ваше API:
Изменения в схеме бд
Итого, в модели (или в таблице БД, если угодно) надо хранить:
История с предысторией
Идеальный телефон, как верный пёс, должен узнавать хозяина по запаху и охранять имущество от посторонних.
Собаки свой нюхательный аппарат развили за миллионы лет эволюции, а нашим технологиям всего ничего, поэтому телефоны пока неидеальны.
У людей с нюхом намного хуже, поэтому в их естественной среде обитания пришлось разрабатывать искусственные системы опознания, такие как подорожная грамота, условные жесты и конспиративные пароль и отзыв.
Когда же люди стали перекладывать часть своих задач на цифровые плечи, поначалу никакой программной аутентификации не существовало – запускать программный код мог любой желающий, получивший доступ в машинный зал. Но уже тогда этот самый доступ регулировался определёнными правилами, описанными, например, в уставе караульной службы и прочих регламентах с допусками.
Как в сексе: чем позже — тем лучше
Заставляете пользователя проходить авторизацию или регистрироваться в вашем приложении сразу после того, как он его загрузил и открыл в первый раз? Значит, увеличиваете шансы приложения незамедлительно оказаться в корзине. Это подтверждается статистикой, поэтому наш первый совет: вставляйте авторизацию до момента, когда она действительно необходима. Это может быть отправка заказа или создание комментария. Вот небольшая
статья на тему.
Номер телефона и код подтверждения
Валидация ввода номера — задача непростая из-за проверки страны и маски ввода. Здесь отчасти может помочь
библиотека от Google.
В Android можно сделать автокомплит номера из SIM-карты, однако это работает не на всех устройствах, поэтому в коде нужно учитывать возможные ошибки. На практике я не нашёл приложений, которые так делают, но применение такого способа вполне допустимо.
После ввода и отправки номера пользователю нужно ввести код из SMS. Android-приложение может делать это автоматически. Этот прием используют Viber, Telegram, Rocketbank. Важно лишь объяснить пользователю, что скоро придёт SMS, нужно только немного подождать.
Особенности реализации мобильного приложения
В случае Android полученный токен можно хранить в SharedPreferences (почему не AccountManager), а для iOS в KeyChain. См. обсуждение на SoF.
Особенности реализации одноразовых паролей
Вам потребуется хранить специальный ключ для проверки СМС-кодов. Существует алгоритм TOTP, который, цитирую Википедию:
OATH-алгоритм создания одноразовых паролей для защищенной аутентификации, являющийся улучшением HOTP (HMAC-Based One-Time Password Algorithm). Является алгоритмом односторонней аутентификации — сервер удостоверяется в подлинности клиента. Главное отличие TOTP от HOTP это генерация пароля на основе времени, то есть время является параметром[1]. При этом обычно используется не точное указание времени, а текущий интервал с установленными заранее границами (например, 30 секунд).
Грубо говоря, алгоритм позволяет создать одноразовый пароль, отправить его в СМС, и проверить, что присланный пароль верен. Причём сгенерированный пароль будет работать заданное количество времени. При всём при этом не надо хранить эти бесконечные одноразовые пароли и время, когда они будут просрочены, всё это уже заложено в алгоритм и вы храните только ключ.
Пример кода на руби, чтобы было понятно о чём речь:
totp = ROTP::TOTP.new("base32secret3232")
totp.now # => "492039"
# OTP verified for current time
totp.verify("492039") # => true
sleep 30
totp.verify("492039") # => false
Алгоритм описан в стандарте 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 и поддерживается тем же набором библиотек, что представлен выше. Пример кода на руби:
hotp = ROTP::HOTP.new("base32secretkey3232")
hotp.at(0) # => "260182"
hotp.at(1) # => "055283"
hotp.at(1401) # => "316439"
# OTP verified with a counter
hotp.verify("316439", 1401) # => true
hotp.verify("316439", 1402) # => false
Получение кода проверки и вход в систему с использованием двухфакторной аутентификации
После включения двухфакторной аутентификации для входа в систему с использованием идентификатора Apple ID на новом устройстве или в браузере потребуется вводить код проверки.
Шифрование
С появлением вычислительных сетей выяснилось, что пароль в открытом виде передавать опасно, так как его по дороге может перехватить злоумышленник. Логичным решением было внедрить шифрование пароля. Так появились Digest Authentication и NTLM. Пользователь вводит всё те же данные, но «по проводам» они передаются в закодированном виде.
Заключение
Вышеописанный подход позволит вам в рамках вашего стека технологий реализовать указанную задачу. Если вас есть соображения по этому подходу или альтернативные подходы, то прошу поделиться в комментариях. Аналогичная просьба, если у вас есть примеры документации к безопасным