Сервис усиленной аутентификации по отпечатку пальца
Постановка задачи
При обращении к публичным интернет-сервисам (web-почта, депозитарии файлов, социальные сети, и т.п.), имеющих традиционную систему входа Логин-Пароль, в ряде случаев у пользователей могут возникать проблемы, связанные с несанкционированным доступом посторонних к их личным данным, хранящимся на удаленных серверах.
Наиболее актуальной является следующая модель угроз: нарушитель знаком с пользователем и каким-либо образом похищает его пароль, не используя при этом изощренных средств.
Другие модели нарушителя, включая возможности доступа технического персонала, обслуживающего данные сервисы, спецслужб (СОРМ), хакеров и прочих «случайных» и «продвинутых» нарушителей, являются менее актуальными с точки зрения «рядового» пользователя публичного сервиса.
Еще один существенный аспект, который надо учитывать – пользователь не сразу осознает необходимость усиления защиты. К примеру, в личном почтовом ящике, которым пользователь иногда пользуется, и содержимое которого по ряду причин предпочитает хранить на удаленном сервере, с течением времени накапливается множество писем, адресов, вложений, которые в совокупности начинают представлять для него все большую ценность. Пользователь начинает задумываться об усилении защиты своих персональных данных от несанкционированного доступа определенного круга «своих знакомых».
Требования, предъявляемые к такого рода дополнительной защите, кратко можно сформулировать следующим образом:
- простота в использовании, возможность выбора альтернативных способов усиления аутентификации;
- возможность простого подключения в уже работающий сервис.
Ниже предлагается один из возможных вариантов организации защиты, основанном на аутентификации по отпечатку пальца.
Основные требования к продукту
Решение проблемы «защиты от своих»;
Совместимость с существующими публичными сервисами (почта, хранилища файлов, … );
Прозрачная для пользователя автоматическая установка клиента;
Функционирование системы
Система может функционировать в двух основных режимах: режиме регистрации и режиме аутентификации. Рассмотрим их более подробно. На рис.1 представлена схема работы при регистрации сервиса. В большинстве случаев в момент внедрения системы сайт уже существует и пользователи зарегистрированы по логину/паролю. В этом случае регистрация возможна лишь после того, как пользователь вошел на сайт обычным способом (именно этот случай представлен на рис.1).
После входа в систему он видит ссылку с возможностью подключения сервиса. При нажатии на ссылку управление передается в модуль расширения сервера. Если у пользователя на данный момент еще не установлен клиент, ему предлагается скачать установщик программы-клиента и после установки продолжить регистрацию. Иначе модуль расширения сервера передает IP-адрес и логин пользователя в функцию для регистрации, вызываемую из библиотеки WebAuth.dll. Эта функция устанавливает соединение с клиентом и запрашивает модель отпечатка. Сканер работает в режиме обучения, после обучения модель отпечатка передается WebAuth.dll по защищенному каналу. Библиотека передает логин/шаблон отпечатка на запись в БД сервиса. Пользователь зарегистрирован.
Работа системы в режиме аутентификации представлена на рис. 2. Порядок работы похож не предыдущий, только из БД сервиса извлекается ранее записанный шаблон и сравнивается с полученным, модулю расширения сервера возвращается результат сравнения, и этот модуль уже выдает либо вход в личную комнату, либо страницу с сообщением об ошибке.
Состав продукта
1. Серверный модуль
2. СУБД для серверного модуля
3. Клиентский модуль
Серверный модуль (WebAuth.dll) – представляет собой программную библиотеку и предоставляет программистам сайта API из нескольких простых функций.
Аргументы в пользу такой формы серверного модуля:
На разных сайтах используются разные СУБД
Структура БД предприятия/сайта достоверно неизвестна
Возможны различия даже в названиях полей БД предприятия (Login, Name,…)
Прямой доступ к БД предприятия из серверного модуля может требовать настройки параметров ее безопасности, может вызвать недоверие со стороны администрации сайта. Программная библиотека же позволяет абстрагироваться от доступа к БД предприятия, программисты сайта сами осуществляют его и передают в функции библиотеки готовые значения.
Далее, внедрение сервиса WEB-аутентификации – это изменение функциональности сайта, что в любом случае нельзя делать без программистов сайта и дизайнеров. Как минимум, серверный модуль не должен участвовать в генерации html-страниц, т.к. для большинства социальных сетей очень важен их дизайн.
Недостаток – повышается объем работы по внедрению. Но функции библиотеки простые, количество дополнительного кода невелико, изменение, например, страницы входа в систему может свестись к добавлению ссылки на модуль, вызывающий функции библиотеки.
Клиент представлен в виде приложения, которое запускается со стартом ОС, находится в трее (запуск испытан). В момент сканирования клиент активируется и предлагает пользователю отсканироваться (испытано).
Модуль расширения веб-сервера пишут программисты сайта. Модуль необходим, чтобы абстрагировать библиотеку от особенностей сайта и интегрировать ее в существующую систему. К примеру, аутентификация используется параллельно с обычной или после ввода пароля требуется дополнительно отсканировать палец? Регистрация сервиса возможна после входа в систему обычным способом, это тоже обеспечивает модуль расширения, обращаясь к уже существующей БД сайта. Данный модуль также реализует все особенности политики безопасности сайта. В случае, если от пользователя не приходит шаблон отпечатка, библиотека возвращает соответствующий код ошибки, а данный модуль может предложить пользователю отсканироваться еще раз. Представляет собой CGI-программу или ISAPI библиотеку. Простейший вариант модуля будет в составе примера.
Параллельно с клиентом и сервером готовится пример веб-приложения, несколько страниц, которые генерируются CGI-программами.
Предположения и свойства системы
1. В БД сайта логин является первичным ключом.
2. Изменение логина невозможно, можно только удалить логин (и всю учетную запись/почтовый ящик и т.д.) и создать новый
3. На один логин (учетную запись) зарегистрирован только один человек. Или, если даже их несколько, возможно зарегистрировать только один шаблон отпечатка
4. Услуга не привязывается к конкретному ПК, но требует BioLink-совместимый сканер
5. Для работы услуги у клиента должен быть установлен кроме сканера клиент, прописан в авторане, пользователь не должен остановить процесс клиента. При подключении услуги пользователю предлагается скачать прямо с сайта пакет инсталляции клиента (+новые драйвера для BioLink, если нет проблем с лицензированием) + возможность использовать встроенные сканеры ноутбука, но это потом
6. Есть функция удаления шаблона из БД, остается только обычный способ доступа
7. Возможно изменить шаблон, удалив старый и зарегистрировав новый
8. Сервис действует параллельно с обычным способом Логин/Пароль, является опциональным (подключается по желанию пользователя) и следует за вводом пароля, если это предусмотрено политикой безопасности пользователя
9. Сервис представляет только сравнение 1:1, всегда требует ввода логина
10. Функции API не берут на себя высокую степень самостоятельности. Например, если распознавание с первого раза неуспешное, так и говорится. Если надо, функцию можно вызвать еще раз, политику безопасности вроде возрастающих задержек между попытками и лимит попыток определяют программисты сайта. Если данного логина нет в нашей БД – возвращается соответствующий код ошибки. Если надо, программисты сайта сами вызывают функцию для регистрации шаблона
11. Синхронизации паролей нет - он не хранится в нашей БД, там только логин/шаблон
12. При удалении учетной записи синхронизация требуется, должна быть вызвана соответствующая функция
13. Библиотека возвращает лишь коды ошибок, страницы сообщений об ошибках верстают дизайнеры
Работа компонентов системы
На рис. 3 представлена более детализированная схема системы. Рассмотрим работу компонентов и порядок их работы.

Пользователь заходит на страницу входа в систему. Раньше были элементы для ввода логина, пароля, кнопки ОК, Отмена. Теперь добавлена еще одна кнопка – «Вход по отпечатку». Т.е. альтернатива – либо пароль, либо отпечаток. Это один вариант. Другой – дополнительно возникает предложение ввести отпечаток, если это установлено ранее в политике безопасности. Кроме того надо добавить опцию -токен, если пользователь это предпочитает. Классическая мнгофакторная схема.
Пользователь вводит свой логин или нажимает эту кнопку. Браузер передает значение логина модулю расширения WEB-сервера, например, CGI-программе. Эта программа может проверить наличие такого логина в БД сайта (а может и не проверять). При наличии вызывает функцию для аутентификации из библиотеки WebAuth.dll, передает ей значение логина. Когда управление переходит в функцию аутентификации, она посылает команду активации клиенту. Клиент резидентный, с помощью слушающего сокета проверяет некоторый порт. Приняв команду, активируется, предлагает пользователю сканировать палец. Если связь не устанавливается, выдается соответствующий код ошибки, модуль расширения может выдать страницу («запущен клиент? Если клиент не установлен, скачайте его») После сканирования шаблон по защищенному каналу передается в WebAuth.dll. Последний, в свою очередь, по принятому логину извлекает из БД ранее зарегистрированный шаблон, передает оба шаблона функциям BSDK и возвращает результат или код ошибки модулю расширения WEB-сервера. Этот модуль либо генерирует страницу с сообщением об ошибке, либо вход в личную комнату.
Технология
Используется Delphi 7, BSDK 4.7, связь клиента и сервера – Indy 9 (+OpenSSL). В качестве СУБД для серверного модуля пока используется MS-SQL Server 2000, здесь возможны изменения. Доступ к данной БД – через ADO (возможны изменения), установщик клиента – InstallShield 2008. Тестирование под Windows XP.
API библиотеки предоставляется в виде:
Заголовочных с-файлов
Модулей для Delphi
Библиотека физически представлена в виде одной или нескольких DLL.
|