Fingerprint authentication что это
Проверка подлинности по отпечаткам
В этом руководстве описано добавление проверки подлинности по отпечаткам, представленную в Android 6.0, в приложение Xamarin.Android.
Обзор проверки подлинности по отпечаткам
Появление сканеров отпечатков на устройствах Android предоставляет приложению альтернативу традиционному методу проверки подлинности пользователя по имени пользователя или паролю. Использование отпечатков для проверки подлинности пользователя позволяет включить в структуру приложения безопасность, которая является менее навязчивой, чем имя пользователя и пароль.
FingerprintManager (а также его аналог библиотеки поддержки FingerprintManagerCompat) является основным классом для использования оборудования сканирования отпечатков. Этот класс является программой-оболочкой пакета SDK для Android для службы уровня системы, которая управляет взаимодействием с самим оборудованием. Он отвечает за запуск сканера отпечатков и реагирование на отзыв от сканера. Этот класс имеет довольно простой интерфейс с тремя членами.
В этом руководстве объясняется использование API FingerprintManager для улучшения приложения Android с проверкой подлинности по отпечаткам. В нем рассматривается создание экземпляров и CryptoObject для защиты результатов сканера отпечатков. Мы рассмотрим, как приложение должно создать подкласс FingerprintManager.AuthenticationCallback и реагировать на отзывы от сканера отпечатков. Наконец, мы узнаем, как зарегистрировать отпечаток на устройстве или эмуляторе Android и как использовать adb для имитации сканирования отпечатков.
Requirements (Требования)
Для проверки подлинности по отпечаткам требуется Android 6.0 (API уровня 23) или более поздней версии и устройство со сканером отпечатков.
Отпечаток пальца следует зарегистрировать на устройстве для каждого пользователя, который должен пройти проверку подлинности. Это включает в себя настройку блокировки экрана, которая использует пароль, ПИН-код, схему прокрутки или распознавание лиц. Некоторые функции проверки подлинности по отпечаткам можно имитировать в Android Emulator. Дополнительные сведения об этих двух разделах см. в статье Регистрация отпечатка пальца.
Android Fingerprint API: приделываем аутентификацию по отпечатку
Привет, Хабр! Прошло достаточно много времени, как появился Fingerprint API для Android, в сети много разрозненных сэмплов кода по его внедрению и использованию, но на Хабре по какой-то причине эту тему обходили стороной. На мой взгляд, настало время исправить это недоразумение. Всех заинтересовавшихся прошу под кат.
Кратчайший ликбез
Итак, что же представляет собой Fingerprint API? API позволяет пользователю аутентифицироваться посредством своего отпечатка, очевидно. Для работы с сенсором API предлагает нам FingerprintManager, достаточно простой в освоении.
Как его использовать? А вот это уже интереснее. Практически везде, где требуется аутентификация по паролю, можно прикрутить аутентификацию по отпечатку. Представьте себе приложение, состоящее из LoginActivity и MainActivity. При запуске мы попадаем на экран логина, вводим пин-код, проходим к данным. Но мы хотим заменить вход по пин-коду на вход по отпечатку. К слову, полностью заменить не получится, мы можем лишь избавить пользователя от ручного ввода пин-кода, подставляя ранее сохраненный пин-код (имеется ввиду клиент-серверное приложение, в котором нужно отправить пароль серверу).
Где сенсор?
Чтобы начать получать профит от нового API, первым делом нужно добавить permission в манифесте:
Само собой, использовать Fingerprint API можно только на устройствах, его поддерживающих: соответственно, это устройства Android 6+ с сенсором.
Совместимость можно легко проверить с помощью метода:
FingerprintManagerCompat — это удобная обертка для обычного FingerprintManager’а, которая упрощает проверку устройства на совместимость, инкапсулируя в себе проверку версии API. В данном случае, isHardwareDetected() вернет false, если API ниже 23.
Дальше, нам нужно понять, готов ли сенсор к использованию. Для этого определим enum состояний:
И воспользуемся методом:
Код достаточно тривиальный. Небольшое недопонимание может вызвать момент, когда мы проверяем заблокировано ли устройство. Нам нужна эта проверка, так как, хоть Android и не позволяет добавлять отпечатки в незащищенное устройство, некоторые производители это обходят, поэтому подстраховаться не помешает.
Различные состояния можно использовать для того, чтобы дать пользователю понять, что происходит и направить его на путь истинный.
Подготовка
Итак, не зацикливаясь на проверке пин-кода на валидность, прикинем следующую упрощенную логику действий:
Что нам нужно для шифровки и расшифровки:
Хранилище
Для работы с отпечатками система предоставляет нам свой кейстор — “AndroidKeyStore” и гарантирует защиту от несанкционированного доступа. Воспользуемся им:
Следует принять, понять и простить, что кейстор хранит только криптографические ключи. Пароли, пин и другие приватные данные там хранить нельзя.
На выбор у нас два варианта ключей: симметричный ключ и пара из публичного и приватного ключа. Из соображений UX мы воспользуемся парой. Это позволит нам отделить ввод отпечатка от шифрования пин-кода.
Ключи мы будем доставать из кейстора, но сначала нужно их туда положить. Для создания ключа воспользуемся генератором.
При инициализации мы указываем, в какой кейстор пойдут сгенерированные ключи и для какого алгоритма предназначен этот ключ.
Сама же генерация происходит следующим образом:
Здесь следует обратить внимание на два места:
Шифровальщик
Шифровкой и дешифровкой в Java занимается объект Cipher.
Адовая мешанина в аргументе — это строка трансформации, которая включает в себя алгоритм, режим смешивания и дополнение.
После того, как мы получили Cipher, нужно подготовить его к работе. При генерации ключа мы указали, что будем использовать его только для шифровки и расшифровки. Соответственно, Cipher тоже будет для этих целей:
где initDecodeCipher() и initEncodeCiper() следующие:
Нетрудно заметить, что зашифровывающий Cipher несколько сложнее инициализировать. Это косяк самого Гугла, суть которого в том, что публичный ключ требует подтверждения пользователя. Мы обходим это требование с помощью слепка ключа (костыль, ага).
Момент с KeyPermanentlyInvalidatedException — если по какой-то причине ключ нельзя использовать, выстреливает это исключение. Возможные причины — добавление нового отпечатка к существующему, смена или полное удаление блокировки. Тогда ключ более не имеет смысла хранить, и мы его удаляем.
Метод, который собирает всю цепочку подготовки:
Шифровка и расшифровка
Опишем метод, который зашифровывает строку аргумент:
В результате мы получаем Base64-строку, которую можно спокойно хранить в преференсах приложения.
Для расшифровки же используем следующий метод:
Опа, на вход он получает не только зашифрованную строку, но и объект Cipher. Откуда он там взялся, станет ясно позднее.
Не тот палец
Для того чтобы наконец использовать сенсор, нужно воспользоваться методом FingerprintManagerCompat:
Хендлер и флаги нам сейчас не нужны, сигнал используется, чтобы отменить режим считывания отпечатков (при сворачивании приложения, например), коллбеки возвращают результат конкретного считывания, а вот над криптообъектом остановимся поподробнее.
CryptoObject в данном случае используется как обертка для Cipher’a. Чтобы его получить, используем метод:
Как видно из кода, криптообъект создается из расшифровывающего Cipher. Если этот Cipher прямо сейчас отправить в метод decode(), то вылетит исключение, оповещающее о том, что мы пытаемся использовать ключ без подтверждения.
Строго говоря, мы создаем криптообъект и отправляем его на вход в authenticate() как раз для получения этого самого подтверждения.
Если getCryptoObject() вернул null, то это значит, что при инициализации Chiper‘а произошел KeyPermanentlyInvalidatedException. Тут уже ничего не поделаешь, кроме как дать пользователю знать, что вход по отпечатку недоступен и ему придется заново ввести пин-код.
Как я уже говорил, результаты считывания сенсора мы получаем в методах коллбека. Вот как они выглядят:
В случае успешного распознавания мы получаем AuthenticationResult, из которого можем достать объект Cipher c уже подтвержденным ключом:
Теперь можно с чистой совестью отправить его на вход в decode(), получить пин-код, сымитировать его ввод и показать пользователю его данные.
На этом на сегодня всё, замечания, комментарии, предложения и вопросы приветствуются.
Простейший вариант работы кода можете посмотреть на гитхабе.
Аутентификация в мобильных приложениях
История с предысторией
Идеальный телефон, как верный пёс, должен узнавать хозяина по запаху и охранять имущество от посторонних.
Собаки свой нюхательный аппарат развили за миллионы лет эволюции, а нашим технологиям всего ничего, поэтому телефоны пока неидеальны.
У людей с нюхом намного хуже, поэтому в их естественной среде обитания пришлось разрабатывать искусственные системы опознания, такие как подорожная грамота, условные жесты и конспиративные пароль и отзыв.
Когда же люди стали перекладывать часть своих задач на цифровые плечи, поначалу никакой программной аутентификации не существовало – запускать программный код мог любой желающий, получивший доступ в машинный зал. Но уже тогда этот самый доступ регулировался определёнными правилами, описанными, например, в уставе караульной службы и прочих регламентах с допусками.
Скоро этого стало не хватать. У первобытных программистов появились идентификаторы, затем логин с паролем – и вот перед нами классическая 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-ки, вполне вероятно, что эта ваша активность будет сохранена навечно (в рамках существования нашей цифровой вселенной).
Что же касается других применений, то известно, что в Китае придумали посредством блокчейн отслеживать, что случалось в жизни кур, попадающих на стол особых ценителей высокой кухни.
Проектировщики будущего! Пожалуйста, постарайтесь, чтобы наши гаджеты узнавали своих хозяев не хуже собаки, при этом, по возможности, обходясь без собачьего корма, и чтобы их не нужно было слишком часто выгуливать.
Автор этих строк также выражает надежду на то, что его телефон лет через десять не удастся приманить и облапошить аппетитно пахнущей сосиской.
Отпечаток браузера: что это, как работает, нарушает ли закон и как защититься. Часть 1
От Selectel: эта статья первая в цикле переводов очень детальной статьи об отпечатках браузера и том, как работает технология. Здесь собрано все, что вы хотели знать, но боялись спросить по этой теме.
Что такое отпечатки браузера?
Это метод, используемый сайтами и сервисами для отслеживания посетителей. Пользователям присваивается уникальный идентификатор (отпечаток). Он содержит много информации о настройках и возможностях браузера пользователей, что используется для их идентификации. Кроме того, отпечаток браузера позволяет сайтам отслеживать поведенческие паттерны, чтобы впоследствии еще точнее идентифицировать пользователей.
Уникальность примерно такая же, как у реальных отпечатков пальцев. Только последние собирает полиция для поиска подозреваемых в совершении преступлений. А вот технология отпечатка браузеров применяется вовсе не для отслеживания преступников. Ведь мы же здесь не преступники, верно?
Какие данные собирает отпечаток браузера?
О том, что человека можно отследить по IP, мы знали еще на заре существования интернета. Но в данном случае все гораздо сложнее. Отпечаток браузера включает IP-адрес, но это далеко не самая важная информация. На самом деле, для того, чтобы идентифицировать вас, IP не нужен.
Согласно исследованию EFF (Electronic Frontier Foundation), отпечаток браузера включает в себя:
Согласно еще одному исследованию, точность идентификации пользователя при помощи отпечатка браузера составляет 99,24%. Изменение одного из параметров браузера снижает точность идентификации пользователя лишь на 0,3%. Существуют тесты на отпечаток браузера, которые показывают, насколько большой объем информации собирается.
Как работает отпечаток браузера
Почему вообще возможен сбор информации о браузере? Все просто — ваш браузер обменивается данными с веб-сервером, когда вы запрашиваете адрес сайта. В обычной ситуации сайты и сервисы присваивают пользователю уникальный идентификатор.
Эта строчка из случайных букв и цифр помогает серверу узнать ваc, ассоциировать ваш браузер и ваши предпочтения с вами. Действиям, которые вы совершаете онлайн, будет присвоен примерно тот же код.
Так, если вы зашли в Twitter, где есть какая-то информация о вас, все эти данные будут автоматически связаны с тем же идентификатором.
Конечно, этот код не будет с вами до конца ваших дней. Если вы начнете серфить с другого устройства или браузера, то идентификатор, скорее всего, тоже поменяется.
Как сайты собирают пользовательские данные?
Это двухуровневый процесс, который работает как на стороне сервера, так и на стороне клиента.
На стороне сервера
Логи доступа к сайту
В этом случае речь идет о сборе данных, отправляемых браузером. Как минимум это:
Веб-серверы получают их от вашего браузера. Заголовки важны, поскольку они позволяют быть уверенным, что запрошенный сайт работает с вашим браузером.
Например, информация в заголовке позволяет сайту узнать, используете ли вы ПК или мобильное устройство. Во втором случае произойдет редирект на оптимизированную для мобильных устройств версию. К сожалению, эти же данные попадут в ваш отпечаток.
Здесь все понятно. Веб-серверы всегда обмениваются куки с браузерами. Если вы в настройках указываете возможность работы с куки, они сохраняются на вашем устройстве и отправляются на сервер, когда бы вы ни зашли на сайт, который уже посещали прежде.
Куки помогают серфить более комфортно, но они же открывают и больше информации о вас.
В этом методе используется элемент холста (canvas) HTML5, который WebGL также использует для визуализации 2D- и 3D-графики в браузере.
Этот метод обычно «заставляет» браузер обрабатывать графический контент, включая изображения, текст или то и другое разом. Для вас этот процесс незаметен, поскольку все происходит в фоне.
Как только процесс завершен, canvas fingerprinting превращает графику в хэш, который становится тем самым уникальным идентификатором, о котором мы говорили выше.
Этот метод позволяет получать следующую информацию о вашем устройстве:
Здесь подразумевается, что ваш браузер обменивается большим количеством информации благодаря:
Adobe Flash и JavaScript
Согласно FAQ AmIUnique, если у вас активирован JavaScript, то вовне передаются данные о ваших плагинах или спецификациях железа.
Если установлен и активирован Flash, то это предоставляет стороннему «наблюдателю» еще больше информации, включая:
Они играют очень важную роль в логировании. Так, вам обычно нужно решить, позволить ли браузеру обрабатывать куки или полностью удалить их.
В первом случае веб-сервер получает просто огромное количество информации о вашем устройстве и предпочтениях. Если вы не одобрите работу с куки, сайты все равно получат кое-какие данные о вашем браузере.
Зачем нужна технология отпечатка браузера?
В основном для того, чтобы пользователь устройства получил оптимизированный для его устройства сайт, вне зависимости, зашел он в интернет с планшета или смартфона.
Кроме того, технология используется для рекламы. Это просто идеальный инструмент дата-майнинга.
Так, получив собранную сервером информацию, поставщики товаров или услуг могут создавать очень тонко нацеленные рекламные кампании с персонализацией. Точность таргетирования гораздо выше, чем если использовать просто IP-адреса.
Например, рекламщики могут использовать отпечатки браузеров для того, чтобы получить список пользователей сайта, разрешение экрана которых можно назвать низким (например, 1300*768), кто ищет более качественные мониторы в интернет-магазине продавца. Или же пользователей, которые просто серфят по сайту без намерения что-либо купить.
Затем полученную информацию можно использовать для таргетирования рекламы качественных мониторов с высоким разрешением на пользователей с небольшим и устаревшим морально дисплеем.
Кроме того, технология отпечатка браузера используется еще и для:
В конечном счете, даже если отпечатки браузера используются в законных целях, это все равно очень плохо сказывается на конфиденциальности пользователей. Особенно если последние пытаются защититься при помощи VPN.
Кроме того, отпечатки браузера могут быть лучшим другом хакера. Если им известны точные данные о вашем устройстве, они могут использовать специальные эксплойты для взлома устройства. В этом нет ничего сложного — любой киберпреступник может создать поддельный сайт со скриптом снятия отпечатков пальцев.
Напомним, эта статья — только первая часть, впереди еще две. В них рассматриваются вопросы законности сбора персональных данных пользователей, возможности использования этих данных и методы защиты против слишком уж активных «собирателей».