Аутентификация в мобильных приложениях

    История с предысторией


    Идеальный телефон, как верный пёс, должен узнавать хозяина по запаху и охранять имущество от посторонних.

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

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

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

    Скоро этого стало не хватать. У первобытных программистов появились идентификаторы, затем логин с паролем – и вот перед нами классическая Basic Authentication протокола HTTP.

    Логин и пароль


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

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

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

    Почему нельзя обойтись только логином? Теоретически можно, а практически очень неудобно. Логин фигурирует в формах запросов и отчётах, его иногда приходится сообщать в службу поддержки. Сделав логин трудным для подбора и скрытым от окружающих, мы уподобим его паролю. А чтобы как-то отображать публичную информацию по нашей учётной записи, придётся добавить новое поле – скажем, ник, – что сделает всё затею не заслуживающей усилий.

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

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

    Можно было бы добавить, что всё здесь хорошо и ничего менять не надо, но – нет.

    Шифрование


    С появлением вычислительных сетей выяснилось, что пароль в открытом виде передавать опасно, так как его по дороге может перехватить злоумышленник. Логичным решением было внедрить шифрование пароля. Так появились Digest Authentication и NTLM. Пользователь вводит всё те же данные, но «по проводам» они передаются в закодированном виде. Расшифровать или взломать их, в принципе, специалисты могут, однако это всё равно надёжнее отправки пароля открытым текстом.

    Интересующихся защищёнными каналами связи мы отсылаем к изучению протокола HTTPS, SSL и TLS, а сами движемся дальше, к постижению мобильного дао.

    Single-Sign-On


    Другим неприятным аспектом всеохватного запароливания оказалось, что не очень-то удобно держать в голове больше одной-двух пар логина и пароля, вводить их всякий раз при входе в программу, особенно если этих программ больше одной. Результатом решения проблемы стали аутентификация oAuth и принцип SSO, то есть Single-Sign-On (войти один раз).

    Идея oAuth проста. Вместо того чтобы каждый раз требовать у пользователя его логин и пароль, лучше сделать это один раз, на основании полученных сведений получить так называемый токен у доверенного сервера и далее проводить операции уже с этим токеном. Это особенно удобно в контексте обмена данными между мобильным или web приложением и удалённым сервером, где аутентифицирующие сведения (credentials) необходимо передавать с каждым запросом.

    SSO решает немного другую задачу.

    В рамках web все приложения, использующие один и тот же доверенный сервер для oAuth-аутентификации (например, сайты с Гугль-аккаунтом), автоматически разделяют между собой сведения пользователя (credentials). То есть, введя логин и пароль в одном приложении, в другое пользователь заходит уже опознанным.

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

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

    Где хранятся пароли


    У читателя, который не просто скользит взглядом по тексту и смог пробиться через предыдущий абзац, должен возникнуть вопрос: а что же это за место такое, где можно безопасно хранить такие чувствительные данные о пользователе, как логин и пароль? Это место специальное, в зависимости от платформы и технологии называемое по-разному, но чаще всего – KeyChain (iOS, Android). Данные здесь шифруются, доступ к ним ограничен – в общем, это самое безопасное место на устройстве, защищённость которого гарантируется на уровне операционной системы.

    Где пароли нельзя хранить


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

    TouchID/Fingerprints


    Широко известно, что человек обладает уникальными отпечатками пальцев. Кроме того, уникальными являются отпечатки носов и ушей, причём если пальцы – атрибут в основном сугубо человеческий, то носы есть и у домашних животных. На практике опознавание по отпечаткам носов используется для идентификации кошек, собак и коров.

    Когда-нибудь, возможно, мы научим наши телефоны опознавать хозяина, просто взяв его в руку, но пока что технология сосредоточилась на дактилоскопии, закрепившейся в криминалистической практике ещё сто лет назад (то, что это очень удобно и для АНБ, мы оставим за рамками статьи).

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

    Face ID


    Последнее новшество от Apple – аутентификация посредством распознавания лица. Если для отпечатков пальцев достаточно теоретически несложной алгоритмической обработки, то для распознавания лиц прибегают к идеям Розенблатта и строят нейросеть.

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

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

    Multifactor authentication


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

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

    Применение данной технологии для мобильных приложений выглядит немного спорным, но вполне возможным.

    Блокчейн и китайские куры


    После того, как биткоин и прочие криптовалюты произвели ажиотажный общественный резонанс, было бы странно, если бы лежащий в основе трансакций этих валют блокчейн не привлёк внимание разработчиков систем безопасности.

    Как же можно задействовать цепочку блоков для аутентификации? Очень просто.

    Применительно к человеку, сама по себе технология блокчейн уже сегодня работает в Эстонии как платформа для электронного гражданства; есть подобные попытки в Бразилии и Финляндии. А японская Sony скрестила MFA и блокчейн (U.S. patent 2017/0310653 A1*). Так что теперь, когда в очередной раз вы где-нибудь введёте код подтверждения из SMS-ки, вполне вероятно, что эта ваша активность будет сохранена навечно (в рамках существования нашей цифровой вселенной).

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

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

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


    * patents.google.com/patent/US20170310653A1/en
    • +6
    • 10,1k
    • 9
    Инфопульс Украина
    97,00
    Creating Value, Delivering Excellence
    Поделиться публикацией

    Похожие публикации

    Комментарии 9

      +2
      Простите, о чём вообще речь? Почему для статьи выбраны именно эти способы аутентификации? Почему исключены другие?
        –2
        Это наиболее типичные способы аутентификации (в мобильных приложениях), с которыми автору приходилось сталкиваться (не считая технологии Sony). Они приведены по принципу нарастания сложности. Если чего-то важного, по вашему мнению, не хватает, прошу сообщить — буду рад добавить в обзор.
          0
          с которыми автору приходилось сталкиваться
          Может быть именно с этого и стоило начать обзор? И может быть стоило немного рассказать об архитектуре протоколов, как их отлаживать, как настаивать? В статье не очень понятно в каком случае какому протоколу отдавать предпочтение. Тот же — SSO — это не только oAuth. Kerberos это же тоже SSO, только в рамках домена, чтобы пользователю не приходилось вводить пароль при подключении к каждому ресурсу. Можно ведь сделать, например, двухфакторную аутентификацию на основе kerberos. Можно сделать n-уровневую аутентификацию в принципе. Ведь читателю в принципе не понятно, а что такое уровень вообще?
            0
            Да, это интересный аспект, какой из протоколов выбрать. Спасибо!
            В принципе, можно было бы составить сводную табличку с пересечением критериев/требований и подходящих протоколов — но тут, как мне видится, слишком много факторов.
              0
              Слишком много факторов?
              Я бы анимированные гифки вставил, например, а то название способов аутентификации — это просто набор символов. И если читатель их ни разу не видел, то для него они так и останутся названиями.
          0
          автор молодец, приятно читать инфу. Особую благодарность выражу за проведенные аналогии, местами комичные. Усваивается определенно легче
            0
            Результатом решения проблемы стали аутентификация oAuth и принцип SSO…

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

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

            А в следующем абзаце поясняете, что речь про пароли. Но в случае с OAuth вам не надо хранить пароли на устройстве.

            Многофакторная аутентификация бывает разная. То, что вы называете пин-кодом на самом деле является одноразовым паролем.

            Про использование блокчейна в задаче аутентификации было бы интересно почитать, жаль что вы ограничились информацией о номере патента и о том, что это это «Очень просто». Возможно, что это неплохая тема для отдельной статьи.
              0
              Про использование блокчейна в задаче аутентификации было бы интересно почитать, жаль что вы ограничились информацией о номере патента и о том, что это это «Очень просто». Возможно, что это неплохая тема для отдельной статьи.

              Спасибо за развёрнутый комментарий. Что касается цитаты, посмотрите на выше приведённую ссылку — там есть не только описание патентуемого метода, но и картинки, из которых, как мне кажется, всё хорошо видно.
              +2
              Статья называется «Аутентификация в мобильных приложениях», а приведён обзор методов аутентификации в принципе.
              в контексте названия интересно было бы более подробно почитать, например, про best practices построения систем авторизации в мобильных приложениях: с OAuth, без неё и тд

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

              Самое читаемое