Анализ алгоритмов аутентификации в распределенных программных системах
Авторы: О.С. Грищенко, А.В. Чернышова
Источник: Программная инженерия методы и технологии разработки информационно-вычислительных систем – 2018 – Донецк, ДонНТУ, с. 102-107.
Аннотация
Грищенко О.С., Чернышова А.В. Анализ алгоритмов аутентификации в распределенных программных системах. Представлен обзор и анализ существующих подходов и алгоритмов аутентификации, используемых в современных распределенных системах. Рассмотрен принцип работы распространенных протоколов аутентификации. Проанализирован протокол аутентификации SQRL и внесены предложения по усовершенствованию данного протокола.
Постановка задачи
На современном этапе развития информационных технологий аутентификация является неотъемлемой частью распределенных программных систем. В связи с ростом ценности информации и появлением новых угроз информационной безопасности задача обеспечения надежной аутентификации пользователя является очень актуальной. Исходя из этого, было решено проанализировать существующие алгоритмы аутентификации, выделить их преимущества, недостатки и уязвимости.
Цель работы
Целью данной работы является анализ общих принципов и конкретных алгоритмов аутентификации в программных системах, изучение существующих алгоритмов и стандартов, анализ возможных уязвимостей и выработка вариантов усовершенствования одного из существующих алгоритмов.
Современные тенденции в области аутентификации
Существует множество способов программно реализовать контроль доступа к электронным ресурсам. Большинство таких способов основаны на процедурах идентификации и аутентификации. Идентификация состоит в присвоении каждому пользователю системы идентификатора. Идентификатор – это специальная информация, которая ставится в соответствие пользователю и полностью определяет его личность для системы. Аутентификация[1] – это процедура проверки принадлежности предъявленного идентификатора пользователю. Можно выделить несколько общих подходов, на которых основывается аутентификация в современных программных системах. Это проверка информации, которой должен обладать пользователь (например, парольная аутентификация[2]), проверка факта обладания пользователем материальным объектом или информационным ресурсом (например, аутентификация по usb-токену[3], криптографическому сертификату[4]), проверка уникальных свойств, присущих пользователю (сюда относится биометрическая аутентификация[5]) и проверка информации, которая имеет отношение к пользователю (на текущий момент представлена аутентификацией по местоположению[6]). Аутентификация может быть односторонней[7], когда проверяется подлинность только одной из сторон участвующих в аутентификации, и двусторонней[8], когда аутентификацию проходят обе стороны. Односторонняя аутентификация обычно используется при парольной или биометрической аутентификации. Двусторонняя аутентификация часто используется при аутентификации на основе сертификатов[9]. По количеству используемых методов аутентификация может быть однофакторной (используется только один метод) и многофакторной (используется не менее двух различных методов). Рассмотрим особенности использования и уязвимости современных методов аутентификации.
Наиболее широкое распространение на текущий момент получила парольная аутентификация, которая имеет множество реализаций, часто отличающихся по уровню защищенности. Концептуально алгоритм парольной аутентификации достаточно прост: при регистрации в системе пользователь задает свой логин (идентификатор) и пароль (аутентификатор). При последующем входе в систему пользователь передает свои логин и пароль, которые сверяются со значениями, хранящимися в системе. Главной проблемой парольной аутентификации является то, что пользователь устанавливает пароль и отвечает за его хранение. Осведомленность рядовых пользователей в вопросах информационной безопасности обычно невысока, что приводит к созданию простых или предсказуемых паролей, которые очень уязвимы перед атаками методом прямого перебора или перебора по словарю. В современных системах этот недостаток пытаются компенсировать путем задания специальных правил и политик (например, обязательное использование цифр, букв в разных регистрах при создании пароля, ограничение по длине пароля, обязательная смена пароля по истечении определенного периода времени) [10]. Такие меры делают пароли более устойчивыми, но усложняют использование пользователем системы. Значительно повысить устойчивость паролей можно, используя генератор паролей, однако сгенерированный пароль трудно запомнить пользователю. Описанные меры не могут защитить пароль пользователя от небезопасного хранения, случайного или намеренного разглашения.
Потенциальными угрозами безопасности является перехват данных[11], используемых при парольной аутентификации, при передаче по сети и хищение базы данных пользовательских учетных записей. При реализации данных угроз множество учетных данных пользователей могут быть скомпрометированы. Очень актуальными описанные угрозы являются для распределенных систем из-за необходимости репликации данных между различными физическими устройствами. Для защиты от подобных угроз в современных системах используют шифрование данных при передаче по сети и хранении вместо паролей хеш-значений[12], сгенерированных криптографически стойкими хеш-функциями.
Один из самых распространенных способов хищения пароля пользователя – это фишинговая атака[13]. Фишинговые атаки могут иметь различные реализации, но все их объединяет то, что пользователи сами передают свои учетные данные злоумышленнику. Рассмотрим обобщенную схему наиболее популярной реализации фишинговой атаки. Пользователь получает сообщение от имени известного ресурса, в котором предлагается перейти по ссылке. Если пользователь переходит по предложенной ссылке, то он попадает на форму аутентификации, копирующую дизайн данного ресурса и вводит свои учетные данные, которые, затем отправляются на сервер злоумышленника. Фишинговые атаки могут использовать спуфинг[14], например, путем регистрации для поддельной страницы аутентификации домена, визуально похожего на домен реального ресурса. Пример реализации описанной схемы представлен на рисунке 1.
Рисунок 1 – Пример реализации фишинговой атаки
Кража учетных данных пользователя также может быть осуществлена с помощью вредоносного программного обеспечения, такого как программы кейлогеры[15].
Более безопасной по сравнению с парольной аутентификацией является аутентификация на основе инфраструктуры открытых ключей - PKI[16]. Работа PKI систем основана на использовании криптографического алгоритма с открытым ключом. PKI системы позволяют проводить аутентификацию пользователей путем проверки их сертификатов. Сертификат выдается каждому пользователю в системе и содержит подписанные с помощью ассиметричного криптоалгоритма данные, идентифицирующие пользователя и его открытый ключ. Выдачей сертификатов занимаются центры сертификации[17]. В реальных системах из-за большого количества пользователей используются множество центров сертификации. При этом образуется иерархическая структура, в которой нижестоящие центры сертификации имеют сертификаты, выданные вышестоящими центрами. В основании такой структуры находится корневой центр сертификации, который использует самоподписанный сертификат[18] и пользуется абсолютным доверием остальных участников системы. На рисунке 2 представлен пример аутентификации пользователя А на ресурсе Б с использованием инфраструктуры открытых ключей.
Рисунок 2 – Пример аутентификации пользователя А на ресурсе Б
PKI системы широко используются в современных программных системах. В частности инфраструктуру открытых ключей использует протокол TLS/SSL[19], который реализует аутентификацию и шифрование данных в рамках протокола HTTPS[20]. Многие компании организуют доступ к своим внутренним ресурсам на основе PKI системы с собственным центром сертификации. PKI системы являются основой для создания сервисов электронной подписи документов и могут быть использованы при реализации аутентификации по usb-токенам или смарт-картам.
Инфраструктура открытых ключей также имеет уязвимости. В частности угрозу для аутентификации, использующей PKI, представляет вирусное программное обеспечение. Например, вредоносная программа, попавшая каким-либо образом на компьютер пользователя может добавить в список доверенных сертификатов сертификат злоумышленника. Это приведет к тому, что злоумышленник и выданные им сертификаты будут пользоваться полным доверием пользователя.
При небезопасном хранении приватный ключ может быть похищен и, в таком случае, злоумышленник сможет осуществлять всевозможные действия от имени пользователя.
В случае, если корневой центр сертификации будет скомпрометирован, то скомпрометированными станут и все сертификаты, которые он выдал.
Аутентификация в PKI системе невозможна, если утеряна связь с центром сертификации.
Для отзыва выданных сертификатов (например, в случае их компрометации) в PKI системах предусмотрен список аннулированных (отозванных) сертификатов. Тем не менее, из-за большого количества территориально распределенных центров сертификации может потребоваться некоторое время для обновления списка аннулированных сертификатов в рамках всей системы. В течении этого времени злоумышленник может продолжать использовать отозванный сертификат.
Все большую популярность в последнее время приобретают биометрические методы аутентификации, основанные на распознавании уникальных свойств конкретного человека. К биометрической аутентификации можно отнести методы, основанные на распознавании лица, рисунка кровеносных сосудов, радужной оболочки и сетчатки глаза, отпечатков пальцев, кисти руки. Одним из недостатков биометрической аутентификации является то, что параметры человека меняются с возрастом и в результате получения травм. Современные программные реализации аутентификации на основе распознавания лица или радужной оболочки глаза можно обмануть с помощью качественной фотографии человека. Уязвимым местом аутентификации, использующей сканирование отпечатка пальца, является то, что люди оставляют свои отпечатки, касаясь окружающих предметов. Таким образом, добыть достаточно качественную фотографию отпечатка пальца не составляет особого труда. А используя фотографию отпечатка пальца, можно обойти аутентификацию, напечатав модель пальца на 3d принтере, или на специальной бумаге с помощью струйного принтера. Аутентификацию по голосу можно обойти, используя программы, позволяющие воспроизводить голос человека по аудио записи, которую также не сложно получить в современных условиях. В реализациях биометрической аутентификации от таких компаний, как Google или Apple базы данных биометрической информации шифруются и хранят результат одностороннего преобразования биометрических данных. Однако не все существующие реализации биометрической аутентификации имеют подобные средства защиты, в связи с чем пользовательские биометрические данные могут быть скомпрометированы. Это особенно важно, учитывая то, что, в отличие от традиционных методов аутентификации, в системах биометрической аутентификацией часто невозможно заменить скомпрометированные данные.
Исследование существующих алгоритмов аутентификации
В стандарте RFC 7235[21] описывается парольная аутентификация для протокола HTTP. Стандарт определяет несколько схем аутентификации. Рассмотрим базовую схему (RFC7617[2]). При отправке от имени неавторизованного клиента запроса к защищенному ресурсу сервер вернет ответ 401 с описанием схемы аутентификации в заголовке. После получения такого ответа клиент запрашивает учетные данные у пользователя и отправляет их на сервер в поле Authorisation. После этого сервер может провести аутентификацию пользователя по полученным данным. В дальнейшем поле Authorisation добавляется к запросам пользователя на данный сервер. Главным достоинством описанного алгоритма, как и большинства алгоритмов парольной аутентификации, является простота реализации. Описанный алгоритм не обеспечивает защиту передаваемых данных, поэтому может использоваться в реальных системах только через защищенное соединение. Серьезной уязвимостью является то, что перехват и расшифровка любого запроса приведут к получению злоумышленником учетных данных пользователя. Данный алгоритм не является защищенным от атак повторного воспроизведения. Также описанная схема не предусматривает какой-либо защиты от фишинговых атак, вредоносного программного обеспечения. Данный алгоритм не может предоставлять достаточного уровня безопасности и поэтому редко используется в реальных системах.
Протокол SSL/TLS получил широкое распространение как средство защиты интернет-коммуникаций. Протокол реализует аутентификацию на основе инфраструктуры открытых ключей, а также шифрование и аутентификацию передаваемых данных.
Аутентификация и согласование ключей в TLS состоит из следующих шагов:
- установка соединения между клиентом и сервером по протоколу TCP[23];
- согласование версии протокола, алгоритмов шифрования, хеш-функции;
- проверка сертификатов (обычно происходит односторонняя аутентификация с проверкой сертификата сервера);
- обмен ключами шифрования по алгоритму RSA[24] или Диффи-Хеллмана[25];
- обмен сообщениями с проверкой MAC[26] кода.
Сам протокол является надежным и безопасным, его спецификация постоянно обновляется для устранения найденных уязвимостей. Благодаря тому, что протокол стал стандартом в области защиты интернет соединений он очень хорошо изучен. Однако многие реализации используют устаревшую спецификацию и не следят за обновлениями протокола (таким образом, не устраняются обнаруженные уязвимости). Также реализации могут использовать небезопасные криптографические алгоритмы (например, md5[27] для подписи сертификатов) или недостаточную длину ключа. Из-за большого количества используемых версий протокола появляется необходимость поддержки старых версий с известными уязвимостями. Введение многочисленных контрмер в ответ на найденные уязвимости вместо пересмотра логики протокола сделали его полную реализацию очень сложной и, в следствие этого, многие реализации протокола имеют ошибки, позволяющие использовать уязвимости, которые считаются устраненными. Из-за того, что рядовые пользователи интернет обычно не имеют сертификатов, TLS может аутентифицировать только сервер, но не клиента на сервере. Для этого приходится использовать другие алгоритмы аутентификации, которые часто становятся слабым местом всей системы. При аутентификации сервера TLS может гарантировать принадлежность домена ресурсу, однако он не может защитить пользователя от ситуации, когда сертификат выдан на домен, визуально похожий на домен другого ресурса (одна из разновидностей спуфинга). Протоколу присущи общие проблемы PKI систем, описанные ранее.
Стандарт ГОСТ Р ИСО/МЭК 9594-8-98[28] — Основы аутентификации описывает два варианта реализации аутентификации — простую и строгую. Простая аутентификация является методом аутентификации, основанным на парольной аутентификации, а строгая аутентификация использует инфраструктуру открытых ключей. Рассмотрим алгоритм строгой аутентификации, который предполагает более безопасную аутентификацию, чем простой вариант. Выдачей сертификатов занимаются уполномоченные по сертификации (аналог центра сертификации инфраструктуре открытых ключей). Уполномоченные по сертификации (УС) могут генерировать два типа сертификатов – срочные, которые выдаются другим участникам системы, и реверсивные, выданные самому себе. Сертификат содержит такую информацию, как имя владельца, публичный ключ и уникальный идентификатор. Перед началом аутентификация строится путь сертификации (список сертификатов, необходимый для получения общего ключа другого пользователя). Стандарт описывает три возможные процедуры строгой аутентификации: однонаправленную, двунаправленную и трехнаправленную. При однонаправленной аутентификации между пользователями А и В происходит одна передача информации, подписанной пользователем А и содержащей уникальный маркер (ra), метку времени (ta), предлагаемый к использованию ключ шифрования (зашифрованный открытым ключом В), идентификатор В и путь сертификации от В к А. Пользователь В сверяет подпись, проверяет параметры ra и ta для защиты от атаки повторного воспроизведения и принимает решения об установлении защищенного соединения с А, используя предлагаемый ключ шифрования. При двунаправленной аутентификации добавляется ответ от В к А, подписанный В и содержащий идентификатор А метки времени tb и ta, маркеры ra и rb, и предлагаемый ключ шифрования, зашифрованный с помощью открытого ключа А. После чего пользователь А проверяет полученные данные. Трехнаправленная аутентификация позволяет не передавать метку времени за счет использования третьей передачи подписанной А информации, содержащей rb идентификатор В.
Строгая аутентификация является достаточно надежной и более защищенной, чем парольная аутентификация, однако требует настройки и поддержки соответствующей инфраструктуры и более сложна в реализации. Стандарт не описывает способа хранения и генерации приватных ключей сертификатов. Если приватные ключи будут создаваться централизовано (например, администратором системы), то, в зависимости от способа передачи и уровня защищенности канала связи, приватные ключи могут быть похищены, что скомпрометирует выданные сертификаты. В случае, если приватные ключи сертификатов будут генерироваться на конечном устройстве пользователя, то при краже устройства или полном копировании носителя информации злоумышленник сможет выдавать себя за этого пользователя. При использовании в качестве хранилища ключа специализированных устройств (например usb-токенов и смарт-карт) существует угроза утери или кражи такого устройства. При неправильном администрировании системы также возможна кража приватных ключей сертификатов. Если конечный пользователь имеет доступ к своему закрытому ключу, то злоумышленник может использовать методы социальной инженерии для получения этого ключа. Однонаправленная и двунаправленная процедуры требуют синхронизации времени, в системе, иначе аутентификация будет уязвима для атак повторного воспроизведения. Реализация описанного алгоритма может быть уязвима при использовании ненадежных алгоритмов шифрования и электронной цифровой подписи или при малой длине ключа шифрования.
Анализ и варианты усовершенствования протокола SQRL
Протокол SQRL[29] разрабатывался как простая в использовании и более защищенная альтернатива парольной аутентификации. При первом запуске приложения на клиенте генерируется мастер ключ, ключ разблокировки личности и задается пароль пользователя. При первой попытке доступа к ресурсу генерируется уникальный приватный ключ на основе мастер-ключа и url службы аутентификации ресурса. На сервере публичный ключ для сгенерированного приватного ключа заносится в базу данных и ассоциируется с пользователем. На рисунке 3 представлена схема аутентификации с помощью протокола SQRL.
Рисунок 3 - Схема работы протокола SQRL
Для того чтобы экспортировать или заменить мастер-ключ используется ключ разблокировки личности, который хранится в зашифрованном виде в распечатываемом QR[30] коде. Расшифровать ключ разблокировки личности можно с помощью 24-х значного кода, который показывается пользователю при генерации ключа разблокировки личности. Мастер-ключ хранится в зашифрованном виде на устройстве пользователя и расшифровывается с помощью пароля пользователя.
Слабым местом в алгоритме защиты протокола SQRL является пароль пользователя. Также потенциальной уязвимостью является то, что пользователь отвечает за хранение кода разблокировки личности. Не смотря на то, что код разблокировки личности зашифрован с использованием произвольно генерируемого 24-значного ключа, пользователь, вероятно, будет хранить этот ключ вместе с кодом разблокировки личности (так как пользователю сложно запомнить 24-х значный код, который он к тому же не использует в повседневной жизни).
Для повышения защищенности можно расширить протокол за счет использования двухфакторной аутентификации при вводе пароля пользователя и при вводе ключа разблокировки личности, например через отправку кода подтверждения на e-mail адрес. А также за счет введения в реализацию клиента правил, не позволяющих генерировать простой пароль. При этом e-mail адреса для аутентификации на ресурсе могут храниться на сервере ресурса и задаваться при регистрации на конкретном ресурсе. А e-mail, используемый для разблокировки личности, может храниться в зашифрованном виде вместе с кодом разблокировки, чтобы исключить возможность подмены e-mail адреса на адрес злоумышленника. В таком случае e-mail, необходимый для активации кода разблокировки личности, может задаваться при первом запуске приложения. Оба типа e-mail адресов могут быть изменены при активации кода разблокировки личности.
Выводы
Был проведен обзор существующих подходов в области аутентификации и проанализированы распространенные алгоритмы аутентификации, рассмотрены их уязвимости преимущества и недостатки. На основе изученных данных можно сделать вывод, что на сегодняшний день существует множество различных подходов к аутентификации, имеющих свои уязвимости и отличающихся по степени защищенности и сложности реализации. Был проведен анализ протокола SQRL и предложены возможные меры по его усовершенствованию.
Литература
1. authentication [Электронный ресурс]. // Search Security. – Режим доступа: https://searchsecurity.techtarget.com/definition/authentication - Загл. с экрана.
2. Парольная аутентификация [Электронный ресурс]. // Volpi. – Режим доступа: http://www.volpi.ru/umkd/zki/index.php?man=1&page=23 – Загл. с экрана.
3. Cryptographic Token Key Initialization Protocol [Электронный ресурс]. // Tools. – Режим доступа: https://tools.ietf.org/html/rfc4758#page-11 – Загл. с экрана.
4. The Basics of Cryptography and Digital Certificates [Электронный ресурс]. // Cryptography. – Режим доступа: https://whatismyipaddress.com/cryptography - Загл. с экрана.
5 Biometric Authentication Overview, Advantages & Disadvantages [Электронный ресурс]. // Heimdal Security. – Режим доступа: https://heimdalsecurity.com/blog/biometric-authentication - Загл. с экрана.
6 Location based authentication [Электронный ресурс]. // Patents. – Режим доступа: https://patents.google.com/patent/US20090187492 - Загл. с экрана.
7. Аутентификация односторонняя [Электронный ресурс]. // Cryptography. – Режим доступа: http://cryptography.ru/docs/аутентификация_односторонняя/ - Загл. с экрана.
8. Двусторонняя аутентификация [Электронный ресурс]. // Studopedia. – Режим доступа: https://studopedia.org/4-95486.html - Загл. с экрана.
9. What Is Certificate-Based Authentication [Электронный ресурс]. // Global Sign. – Режим доступа: https://www.globalsign.com/en/blog/what-is-certificate-based-authentication/ - Загл. с экрана.
10. Как создать надежный пароль [Электронный ресурс]. // Google Support. – Режим доступа: https://support.google.com/accounts/answer/32040?hl=ru – Загл. с экрана.
11. Перехват данных по сети [Электронный ресурс]. // Antimalware. – Режим доступа: https://www.anti-malware.ru/threats/network-traffic-interception - Загл. с экрана.
12. Хэш код [Электронный ресурс]. // Academic. – Режим доступа: https://dic.academic.ru/dic.nsf/ruwiki/1185956 - Загл. с экрана
13.Фишинг [Электронный ресурс]. // Habr. – Режим доступа: https://habr.com/post/344066/ - Загл. с экрана.
14. Спуфинг [Электронный ресурс]. // Avast. – Режим доступа: https://www.avast.ru/c-spoofing - Загл. с экрана.
15. Клавиатурные шпионы [Электронный ресурс]. // Antimalware – Режим доступа: https://www.anti-malware.ru/threats/keyloggers - Загл. с экрана.
16. Public Key Infrastructure [Электронный ресурс] // Tutorialspoint. – Режим доступа: https://www.tutorialspoint.com/cryptography/public_key_infrastructure.htm - Загл. с экрана.
17 Установка центра сертификации на предприятии [Электронный ресурс]. // Habr. – Режим доступа: https://habr.com/company/microsoft/blog/348944/ - Загл. с экрана.
18 Самоподписанный SSL сертификат [Электронный ресурс]. // Emaro-Ssl. – Режим доступа: https://www.emaro-ssl.ru/blog/self-signed-certificate/ - Загл. с экрана.
19. The Transport Layer Security (TLS) [Электронный ресурс] // Tools. – Режим доступа: Protocol https://tools.ietf.org/html/rfc5246- Загл. с экрана.
20. HTTP Over TLS [Электронный ресурс] // Tools. – Режим доступа: https://tools.ietf.org/html/rfc2818 - Загл. с экрана.
21. Hypertext Transfer Protocol (HTTP/1.1): Authentication [Электронный ресурс] // Tools. – Режим доступа: https://tools.ietf.org/html/rfc7235 - Загл. с экрана.
22. The 'Basic' HTTP Authentication Scheme [Электронный ресурс] // Tools. – Режим доступа: https://tools.ietf.org/html/rfc7617 - Загл. с экрана.
23. TRANSMISSION CONTROL PROTOCOL [Электронный ресурс] // Tools. – Режим доступа: https://tools.ietf.org/html/rfc793 - Загл. с экрана.
24. Public-Key Cryptography Standards (PKCS) [Электронный ресурс]. // Tools. – Режим доступа: https://tools.ietf.org/html/rfc3447 - Загл. с экрана.
25. Diffie-Hellman Key Agreement Method [Электронный ресурс]. // IEFT. – Режим доступа: https://www.ietf.org/rfc/rfc2631.txt - Загл. с экрана.
26 HMAC: Keyed-Hashing for Message Authentication [Электронный ресурс]. // IEFT. – Режим доступа: https://tools.ietf.org/html/rfc2104.html - Загл. с экрана.
27. The MD5 Message-Digest Algorithm [Электронный ресурс]. // IEFT. – Режим доступа: https://www.ietf.org/rfc/rfc1321.txt - Загл. с экрана.
28 ГОСТ Р ИСО/МЭК 9594-8-98 Информационная технология [Электронный ресурс]. // CNDT Docs. –Режим доступа: http://docs.cntd.ru/document/1200028710 - Загл. с экрана.
29. Simple Authentication and Security Layer [Электронный ресурс]. // Itu – Режим доступа: https://www.isode.com/products/sasl.html - Загл. с экрана.
30. Introduction to QR Code [Электронный ресурс] // Cgi-Bin – Режим доступа: http://twiki.org/cgi-bin/view/Blog/BlogEntry201102x2 - Загл. с экрана.