Как выполняется идентификация с помощью пароля

Как выполняется идентификация с помощью пароля

Идентификация с помощью паролей. Правила выбора паролей.

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

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

· Пароль представляет собой некоторую последовательность символов, выбранную пользователем.

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

Пароли в виде последовательности символов

Это наиболее известный и часто используемый метод. Достоинством является простота программной реализации проверки паролей, а также удобство для пользователя – ведь пароль, выбранный самостоятельно, легче запомнить. Однако у такого способа есть и серьезные недостатки. Чтобы пароль было легче запомнить, многие пользователи используют в качестве пароля какое-то слово либо имя, либо другую информацию, связанную с жизнью данного пользователя (дату рождения, номер машины и т.д.). Такой пароль легко подобрать, если знать информацию о конкретном человеке.

Что бы повысить надежность парольной защиты, надо соблюдать следующие правила использования паролей:

· пароль должен быть достаточно длинным (не менее 6 символов), иначе его можно подобрать простым перебором всех возможных комбинаций символов.

· пароль не должен быть содержательным словом, так как такие пароли можно взломать путем перебора по словарю; это относится и к словам, напечатанным при другой раскладке клавиатуры (русское слово при английской раскладке и наоборот)

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

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

· если пароль где-то записывается, то эту бумажку надо хранить так, чтобы она не попала в руки посторонних, и чтобы не могла быть ассоциирована с паролем; лучше записывать не сам пароль, а некоторое правело, которое поможет этот пароль вспомнить

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

· некоторые программы поставляются с заранее определенными паролями, указанными в документации. Эти пароли надо немедленно удалить, чтобы никто не смог ими воспользоваться

· пароли надо время от времени менять; а если есть подозрение, что кто-то мог узнать ваш пароль – его надо менять немедленно

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

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

Пароли в виде секретного правила

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

Например, пусть правило выработки пароля следующее: на экран выводится случайное трехзначное число и текущая дата. Пользователь должен сложить две первые цифры числа и номер месяца, и от результата отнять третью цифру числа. Следовательно, если на экран выведено «Вас приветствует 576. Сегодня 15-11-2007», то пароль вычисляется как 5+7+11-6=17.

Недостатком таких «одноразовых» паролей является то, что при «ручном» выполнении правило должно быть достаточно простым (иначе пользователь не сможет его правильно выполнить), а простое правило сможет подобрать злоумышленник, если проанализирует несколько сеансов регистрации в системе. Если же правило сделать достаточно сложным, то для генерации паролей потребуются специальные программные или технические средства.

-сервер присылает на пользовательскую систему число n-1

-пользователь применяет функцию f к секретному ключу K n-1раз и отправляет результат на сервер

Средства защиты паролями объектов Windows

Источник

Парольная защита: прошлое, настоящее, будущее

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

Операционные системы Windows 95/98 сохраняли пароль в PWL файле. PWL файлы хранились в каталоге Windows. Их имена, как правило, хранились как USERNAME.PWL. Вместе с тем стоит отметить, что PWL файл был зашифрован и извлечь из него пароли было не просто. Первый алгоритм шифрования версии Windows’95 был создан так, что позволял создать программы для расшифровки PWL файлов. Однако в версии OSR2 этот недостаток был устранен. Система защиты паролей в OSR2 была сделана профессионально и достоверно в терминах криптографии. Однако, несмотря на это, содержала несколько серьезных недостатков, а именно:

В настоящее время рекомендуемая Microsoft длина пароля для рабочей станции Windows XP должна составлять не менее 8 символов, при этом в пароле должны встречаться большие и маленькие буквы, цифры и спецсимволы. При этом время жизни пароля должно составлять не более 42 дней. К тому же на пароль налагается требование неповторяемости. В дальнейшем эти требования будут только ужесточаться. К чему это приведет, вернее, увы, уже приводит? Чем сложнее пароли, чем больше приложений требуют ввод пароля, тем выше вероятность того, что ваши пользователи для всех приложений, в том числе и для аутентификации в ОС, будут использовать один и тот же пароль или они будут записывать его на бумагу. Хорошо это или плохо? Допустимо ли?

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

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

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

В настоящее время основным способом защиты информации от несанкционированного ознакомления (модификации, копирования) является внедрение так называемых средств AAA (authentication, authorization, administration – аутентификация, авторизация, администрирование).

Стоит учесть, что на мировом рынке ИТ-услуг традиционно растет сегмент ААА. Эта тенденция подчеркивается в аналитических обзорах IDC, Gartner и других фирм.

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

Классификация средств идентификации и аутентификации.

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

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

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

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

Динамическая основывается на анализе действий человека (голос, параметры подписи, ее динамика).

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

Особенности электронных систем идентификации и аутентификации

eToken – персональное средство аутентификации и хранения данных, аппаратно поддерживающее работу с цифровыми сертификатами и электронными цифровыми подписями (ЭЦП). eToken может быть выполнен в виде USB-ключа или стандартной смарт-карты.

eToken поддерживает работу и интегрируется со всеми основными системами и приложениями, использующими технологии смарт-карт или PKI (Public Key Infrastructure).

eToken как средство аутентификации поддерживается большинством современных операционных систем, бизнес-приложений и продуктов по информационной безопасности.

Бесконтактные смарт-карты разделяются на идентификаторы Proximity и смарт-карты, базирующиеся на международных стандартах ISO/IEC 15693 и ISO/IEC 14443. В основе большинства устройств на базе бесконтактных смарт-карт лежит технология радиочастотной идентификации.

Источник

Идентификация и аутентификация с использованием паролей.Основные понятия.

«Управление общеобразовательной организацией:
новые тенденции и современные технологии»

Свидетельство и скидка на обучение каждому участнику

Идентификация и аутентификация с использованием паролей

Основные понятия

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

Идентификация позволяет субъекту (пользователю, процессу, действующему от имени определенного пользователя, или иному аппаратно-программному компоненту) назвать себя (сообщить свое имя). Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает. В качестве синонима слова «аутентификация» иногда используют словосочетание «проверка подлинности».

Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Пример односторонней аутентификации – процедура входа пользователя в систему.

В сетевой среде, когда стороны идентификации/аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта:

1. что служит аутентификатором (то есть используется для подтверждения подлинности субъекта);

2. как организован (и защищен) обмен данными идентификации/аутентификации.

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

1. нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.);

2. нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения);

3. нечто, что есть часть его самого (голос, отпечатки пальцев и т.п., то есть свои биометрические характеристики).

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

Парольная аутентификация

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

Чтобы пароль был запоминающимся, его зачастую делают простым (имя подруги, название спортивной команды и т.п.). Однако простой пароль нетрудно угадать, особенно если знать пристрастия данного пользователя. Известна классическая история про советского разведчика Рихарда Зорге, объект внимания которого через слово говорил «карамба»; разумеется, этим же словом открывался сверхсекретный сейф.

Тем не менее, следующие меры позволяют значительно повысить надежность парольной защиты:

1. наложение технических ограничений (пароль должен быть не слишком коротким, он должен содержать буквы, цифры, знаки пунктуации и т.п.);

2. управление сроком действия паролей, их периодическая смена;

3. ограничение доступа к файлу паролей;

4. ограничение числа неудачных попыток входа в систему (это затруднит применение «метода грубой силы»);

5. обучение пользователей;

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

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

Одноразовые пароли

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

Наиболее известным программным генератором одноразовых паролей является система S/KEY компании Bellcore. Идея этой системы состоит в следующем. Пусть имеется односторонняя функция f (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть, далее, имеется секретный ключ K, известный только пользователю.

Выводы

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

Разработаны пароли, которые генерируются при помощи специальных программ и аппаратуры. Она неуязвимы для таких вариантов подбора, как словарные атаки. В результате этих усилий возникают очень сложные пароли, которые невозможно разгадать и… запомнить. Пользователи попросту записывают их на бумажку, которую прикрепляет на монитор. О какой секретности может идти речь?

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

Такая система делает работу под паролем безопаснее, но лишает её единственного преимущества – простоты и доступности.

Аудит информационной безопасности

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

Основным законом Российской Федерации является Конституция, принятая 12 декабря 1993 года. В Гражданском кодексе Российской Федерации фигурируют такие понятия, как банковская, коммерческая и служебная тайна. Согласно статье 139, информация составляет служебную или коммерческую тайну в случае, когда информация имеет действительную или потенциальную коммерческую ценность в силу неизвестности ее третьим лицам, к ней нет свободного доступа на законном основании, и обладатель информации принимает меры к охране ее конфиденциальности.

Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.

Источник

Обзор способов и протоколов аутентификации в веб-приложениях

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Другие протоколы аутентификации по паролю

Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

Распространенные уязвимости и ошибки реализации

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

Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:

Аутентификация по сертификатам

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

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Пример SWT токена (после декодирования).

Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

Пример подписанного JWT токена (после декодирования 1 и 2 блоков).

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

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

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Источник