openid - Реферат

Икономически университет – Варна

по дисциплината

Безопасност и защита

на тема

“OpenID – протоколи и технологии за автентикация”

Изготвил:

Марин Атанасов - фак. № 10598 59 гр., V курс, спец. Информатика

Варна, 2013

Проверил:

доц. д-р Стефан Дражев х. ас. Видилина Кръстева

Безопасност и защита “OpenID – протоколи и технологии за автентикация”

Марин Страхилов Атанасов, 2013 Стр. 2 от 29

Съдържание Съдържание ........................................................................................................................................... 2 1. Въведение .......................................................................................................................................... 3 2. Предимства на OpenID ...................................................................................................................... 4

2.1. Предимства за обикновените потребители ............................................................................. 4 2.2. Предимства за уебмастери ........................................................................................................ 6

3. Автентикация с OpenID ...................................................................................................................... 7 3.1. Терминология ............................................................................................................................. 7 3.2. Преглед на основните стъпки на OpenID протокола ............................................................... 8 3.3. Форматиране на данните ........................................................................................................... 9

3.3.1. Съобщения на OpenID протокола ...................................................................................... 9 3.3.2. Представяне на целите числа ........................................................................................... 10

3.4. Видове комуникация ................................................................................................................ 11 3.4.1. Директна комуникация ..................................................................................................... 11 3.4.2. Индиректна комуникация ................................................................................................. 11

3.5. Генериране на подписи ........................................................................................................... 13 3.6. Иницииране и откриване ......................................................................................................... 14

3.6.1. Иницииране........................................................................................................................ 14 3.6.2. Нормализация .................................................................................................................... 14 3.6.3. Откриване ........................................................................................................................... 15

3.7. Извършване на връзки (асоциации) ....................................................................................... 15 3.8. Изискване на автентикация ..................................................................................................... 18 3.9. Отговаряне на заявки за автентикация ................................................................................... 20 3.10. Потвърждаване на твърденията ........................................................................................... 22

3.10.1. Потвърждаване валидността на return_url ................................................................... 23 3.10.2. Потвърждаване на откритата информация ................................................................... 23 3.10.3. Потвърждаване на nonce кода ....................................................................................... 23 3.10.4. Потвърждаване на подписите ........................................................................................ 24 3.10.5. Идентифициране на крайния потребител ..................................................................... 24

4. Сигурност в OpenID .......................................................................................................................... 24 4.1. Атаки с подслушване ................................................................................................................ 25 4.2. Man-in-the-middle атаки ........................................................................................................... 25 4.3. Атаки през User Agent............................................................................................................... 26 4.4. Съображения за потребителския интерфейс ......................................................................... 26 4.5. Съображения за HTTP и HTTPS идентификаторите ................................................................ 26 4.6. DDoS атаки ................................................................................................................................. 27

5. Заключение ...................................................................................................................................... 28 6. Използвани източници .................................................................................................................... 29



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

Идентичността е много важна част от уеб и е това, което прави интернет полезен. Повечето полезни сайтове в уеб имат изградена концепция на идентичност. Потребителите влизат в сайта, използвайки своето потребителско име, извършват различна дейност, използвайки акаунта си за известно време и след това излизат. Дали при проверка на e-mail адреса, писане на публикация или коментар в блога, или при купуване на продукт онлайн, потребителите дават на сайта лична информация до известна степен.

Поддържането на идентичности в много и различни сайтове е трудно. Потребителите трябва да се регистрират във всеки сайт, използвайки различно име и парола. Това е доста неудобно и досадно, тъй като много сайтове искат информация, която потребителите вече са дали някъде другаде, а също така запомнянето на различни потребителски имена и пароли е трудно. Какво се случва когато някой вече е заел потребителското име, което даден потребител иска? Повечето хора приключват с избирането на потребителско име, което не им харесва, или просто напускат сайта, като в крайма сметка не се регистрират.

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

OpenID е отворен протокол, който е разработен от различни общности, заинтригувани в намиране на трайно решение на проблема с идентичността. Той е създаден и поддържан като отворен стандарт, който позволява на потребителите да



бъдат разпознавани в множество уебсайтове, които използват услугите на OpenID, което премахва необходимостта за уебмастърите да предоставят на своите собствени специални системи и позволява на потребителите да консолидират своите цифрови идентичности. По този начин всеки потребител може да си създаде профил и след това да го изполва за логване във всеки уебсайт, който приема OpenID удостоверяване. Към началото на 2013 година повече от 30000 уебсайта използват активно OpenID, като сред тях са някои от най-използваните уебсайтове в света - Google, Yahoo!, PayPal, BBC, AOL, LiveJournal, MySpace, IBM, Steam, Orange, VeriSign и др.

2. Предимства на OpenID

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

2.1. Предимства за обикновените потребители

• Ускоряване на процеса по регистрацията в любимите уебсайтове - повечето сайтове продължително изискват информация, за да се използват пълноценно. OpenID ускорява този процес, което позволява логване в различните уебсайтове с едно кликване на мишката. Основните данни (като например име, дата на раждане и място) могат да се съхраняват в потребителския OpenID акаунт и да



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

• Намаляване на неудобствата, свързани с поддържането на множество потребителски акаунти - повечето интернет потребители се затрудняват със запомнянето на множество комбинации от потребителско име и парола, необходими за влизане във всеки един от любимите сайтове. В допълнение към това, процесът на възстановяване на паролата може да бъде досаден. Но използването на една и съща парола за всички любими уеб сайтове, представлява риск за сигурността. С помощта на OpenID, потребителите могат да използват един съществуващ акаунт, за да влязат във всеки един от десетките хиляди сайтове, поддържащи OpenID, без изобщо да е необходимо да се създава друго потребителско име и парола. OpenID е по-безопасен, по-бърз и по-лесен начин за потребителите да се регистрират в нови уеб сайтове, без да губят ценно време в попълване на форми за регистрация.

• Получаване на по-голям контрол върху потребителската онлайн идентичност - OpenID е децентрализиран стандарт, което означава, че не се контролира от всеки уеб сайт или доставчик на услуги. Всеки потребител може да контролира колко лична информация би искал да сподели с уеб сайтовете, които приемат OpenIDs, като в същото време множество OpenID акаунти могат да се използват за различни интернет страници или цели. Ако електронната поща (Google, Yahoo, AOL), фото поток (Flickr) или блог (Blogger, WordPress, LiveJournal) служи като основен акаунт за онлайн присъствието на даден потребител, OpenID позволява този акаунт да се използва като преносима индентичност в други уебсайтове в интернет.

• Свеждане до минимум рисковете, свързани със сигурността на паролата – множество уеб потребители използват една и съща парола в повечето посещавани сайтове. Тъй като традиционните пароли не се администрират централизирано, ако някой от посещаваните уебсайтове има проблем със сигурността, хакер може да получи достъп до потребителската парола, използвана за множество сайтове. С OpenID паролите никога не се споделят с уеб сайтовете, и ако възникне проблем със сигурността, потребителят може просто да смени паролата на своя OpenID акаунт, като по този начин ще спре хакерът от получаване на достъп до потребителските данни.



2.2. Предимства за уебмастери

• Увеличаване на броя регистрации и посещения - дългите формуляри за регистрация представляват основна пречка за регистрирането на потребителите в различните уеб сайтове в Интернет. OpenID опростява процеса на регистрация, като позволява на потребителите да влязат със съществуващ OpenID акаунт с едно кликване, ускорявайки процеса на регистрация. Понеже потребителите, които разполагат с OpenID, могат да влязат в уеб сайта, използвайки съществуващ акаунт, не се налага те да прекарват времето си в създаването на потребителско име или парола специално за конкретния сайт. В допълнение към това, OpenID елиминира нуждата да се насочва новия потребител извън конкретния уеб сайт, за да се провери неговия email адрес, като по този начин се премахва основна пречка при извършването на регистрацията.

• Осигуряване на достъп до богат набор от потребителски данни – интегрирането на OpenID в конкретен уеб сайт дава достъп до богат набор от данни за всеки потребител, които иначе биха изисквали завършването на дълги формуляри за регистрация. Повечето OpenID доставчици събират и обменят широка гама от демографска информация, включително име, дата на раждане, място, пол и email адрес. Тези данни позволяват на уебмастерите да оптимизират маркетинговите си усилия и да адаптират уебсайта така, че да се насочва по-добре към нуждите на основната аудитория, като по този начин предоставя по-пълно съдържание и по-адекватна функционалност, свързана както с географското местоположение на потребителите, така и с техните възраст, пол и др.

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

• Свързване на уебсайта със социалните мрежи - OpenID е градивен елемент за няколко други отворени стандарти, които позволяват да се обогати потребителския интерфейс си и да се свърже уебсайтът с множество социални



мрежи. Протоколи с отворен код като Portable Contacts може да се използва с OpenID за да предостави на уебсайта достъп до адресната книга на потребителя и списъците му с приятели. Потоците с активност от социалните мрежи могат да бъдат интегрирани с помощта на OpenID, за да се даде възможност на потребителите, които се идентифицират с OpenID акаунти да публикуват информация от уебсайта на техните социални мрежи, като по този начин го рекламират и разширяват маркетинговия обхват на уебмастерите.

3. Автентикация с OpenID

Преди да бъде изложена подробно автентикацията с OpenID, както и нейните процедури, трябва да бъдат дефинирани няколко основни понятия и термини, използвани често в тази разработка.

3.1. Терминология

• Идентификатор (identifier) – идентификаторът е „http” или “https” адрес (URL) или Extensible Resource Identifier (XRI).

• User Agent – представлява софтуер, който действа от името на крайния потребител, като в контекста на OpenID е уеб браузърът, който използва потребителя. Важно изискване е използваният уеб браузър да използва HTTP/1.1.

• Разчитаща страна (Relying Party) – уеб приложение или уебсайт, изискващ автентикация от потребителя.

• OpenID доставчик (OpenID Provider) – сървър за автентикация с OpenID, на който разчитащата страна разчита за потвърждение, че крайният потребител е успешно автентициран.

• Краен линк на доставчика (OpenID Provider Endpoint URL) – URL адресът, който приема съобщенията за удостоверяване на OpenID протокола, получени чрез извършване на дейност по откриването на идентификатор, предоставен от потребителя. Крайният линк на доставчика трябва да бъде абсолютен (пълен) HTTP или HTTPS URL адрес.



• Идентификатор на доставчика (OpenID Provider Identifier) – идентификатор (URL адрес или XRI) за конкретния OpenID доставчик.

• Идентификатор, предоставен от потребителя (User-Supplied Identifier) - идентификатор, представен от крайния потребител на разчитащата страна, или избран от потребителя при доставчика на OpenID. По време на иницииращата фаза на протокола, крайния потребител може да въведе своя идентификатор или идентификатора на OpenID доставчика. Ако се използва идентификатора на доставчика, последният може да помогне на крайния потребител при избора на идентификатор, който да бъде споделен с разчитащата страна и в последствие да бъде използван от нея.

• Заявен идентификатор (Claimed Identifier) – идентификатор, който крайният потребител твърди, че притежава. Главната цел на OpenID протокола е да провери това твърдение. Заявеният идентификатор е или такъв, получен при нормализиране на идентификатора, предоставен от потребителя (ако той е URL), или CanonicalID (ако той е XRI).

• Локален идентификатор за OpenID доставчика (OpenID Provider Identifier) – резервен идентификатор за крайния потребител. Този идентификатор е локален за доставчика и не е задължително да е под директния контрол на крайния потребител.

3.2. Преглед на основните стъпки на OpenID протокола

а) Крайният потребител започва удостоверяване чрез представяне на идентификатор, предоставен от потребителя на разчитащата страна чрез своя User-Agent.

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



в) Разчитащата страна и OpenID доставчика се свързват (асоциират) чрез споделена парола, генерирана по алгоритъма за криптиране Дифи-Хелман. Доставчика използва връзката (асоциацията), за да подписва последователните съобщения, а разчитащата страна – за да удостоверява тези съобщения – това премахва нуждата от последователни директни заявки за удостоверяване на подписа след всяка заявка или отговор. Тази стъпка не е задължителна.

г) Разчитащата страна пренасочва User Agent-а на крайния потребител към OpenID доставчика със заявка за OpenID автентикация.

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

е) OpenID доставчикът пренасочва крайния потребител обратно към разчитащата страна, като изпраща и съобщение със статусът на автентикацията – дали е била успешна или се е провалила.

ж) Разчитащата страна проверява информацията, получена от доставчика на OpenID, включително URL адреса за връщане, откритата информация, проверява nonce фразата (nonce е число или фраза, генерирана за целите на криптографската комуникация, предназначена за използване само веднъж, след което става невалидна), както и подписа чрез използване или на споделената парола, генерирана при стъпка в), или чрез изпращане на директна заявка към OpenID доставчика.

3.3. Форматиране на данните

3.3.1. Съобщения на OpenID протокола

Съобщенията при автентикацията на OpenID протокола представляват свързани двойки обикновен текст – ключове и стойности. Те позволяват употребата на всички Unicode символи. Когато ключовете и стойностите трябва да бъдат конвертирани в или от байтове, тяхната кодировка трябва да е UTF-8. Важно ограничение е, че не може да има два или повече параметъра с еднакво име (ключ).



При съобщенията на протокола се спазва последователност от редове, като всеки ред започва с ключ (име), последван от двоеточие, след което следва стойността, асоциирана с конкретния ключ. Всеки ред приключва с единичен символ за нов ред (символ 10 в Unicode, или “\n”). Важно ограничение е, че ключът и стойността не могат да съдържат символ за нов ред и ключът не трябва да съдържа символ за двоеточие. Допълнителни символи, като символ за празно пространство (интервал) не трябва да бъдат добавяни преди или след двоеточието или символа за нов ред. Съобщението трябва да бъде кодирано в UTF-8, за да може да се образува байтова символна поредица.

Когато дадено съобщение се изпраща към HTTP сървъра, то трябва да бъде кодирано с кодировка за форми, а ако към заявката е включен header “Content-Type”, кодировката трябва да отговаря на неговата стойност. Всички ключове в съобщението трябва да започват с „opened.”. Този префикс позволява да се избегнат проблеми с други параметри, които се предават заедно със съобщението за OpenID автентикация. Всички съобщения, които се изпращат като HTTP заявки (GET или POST) трябва да съдържат полетата:

• openid.ns – това поле е задължително, за да може заявката да бъде разчетена като валидна заявка за OpenID автентикация. В стойността на това поле се указва URL, което съдържа номера на версията на OpenID, за която е предназначено съобщението.

• openid.mode – указва вида на съобщението. Това поле е задължително, за да може да съобщението да бъде разчетено като предназначено за OpenID протокола.

3.3.2. Представяне на целите числа

Случайните точни цели числа трябва да бъдат кодирани като шестнадесетични двойки, използвайки функцията btwoc. Всички цели числа, използвани с Дифи-Хелман алгоритъма са положителни. Това означава, че техните най-леви байтове трябва да бъдат нули. В случай че не са, един нулев байт трябва да бъде добавен в началото на символната поредица. Например, “\x00” отговаря на 0, „\x7F” отговаря на 127, а „\x00\x80” отговаря на 128. По-дълъг пример е "\x00\x80\x00", което всъщност отговаря на десетичното число 32768.



3.4. Видове комуникация

3.4.1. Директна комуникация

Директната комуникация е инициирана от разчитащата страна към крайния линк на OpenID доставчика. Тя се използва за извършване на връзките (асоциациите) и валидиране на автентикационните проверки. При директната комуникация съобщението на заявката трябва да бъде кодирано като POST и да бъде изпратено с кодировка application/x-www-form-urlencoded.

При приключване на заявката се получава отговор, който се състои от HTTP отговор във формата на ключ-стойност, както бе посочено в точка 3.3.1. Всички получени съобщения за отговор трябва да съдържат полето ns, което удостоверява съобщението за отговор като валидно за OpenID автентикация. Съобщението за отговор също така съдържа и информация за успеха на заявката – тя може да бъде или успешна, или неуспешна. Ако е успешна, HTTP сървърът трябва да изпрати статус код 200 (OK). В случай, че е неуспешна (което се случва, когато заявката съдържа невалидни или неправилно формирани аргументи), съобщението за отговор съдържа следните полета:

• ns – удостоверява, че заявката е предназначена за OpenID автентикация.

• error – съдържа текст с грешката във вид на обикновен текст.

• contact – адрес за връзка с администратора на сървъра, няма изисквания за неговото форматиране.

• reference - token за референция, например номер на билета за грешка или URL.

3.4.2. Индиректна комуникация

При индиректната комуникация съобщенията се подават през User Agent-а. Това действие може да бъде инициирано както от разчитащата страна, така и от OpenID доставчика. Индиректната комуникация се използва за заявки за автентикация и за нейните отговори.

Има два метода за извършване на индиректна комуникация: HTTP пренасочвания и HTML изпращане на форми. И двата метода изискват изпращача да



знае URL адреса на получателя, и също така получателя да очаква индиректни съобщения. Инициаторът на комуникацията избира кой метод за индиректна комуникация е подходящ в зависимост от размера на съобщението, или други външни фактори. Всички индиректни съобщения се изпращат и пристигат като HTTP заявки, и като такива съдържат задължителните полета, посочени в точка 3.3.1.

При HTTP пренасочването данните могат да бъдат пренесени чрез изпращане на header за 302, 303 или 307 HTTP пренасочване към User Agent-a на крайния потребител. URL адресът, към който се пренасочва е всъщност URL адресът на получателя със съобщението за OpenID автентикация добавено към символния низ на заявката.

При HTML изпращането на форми, двойки ключове-стойности трябва да бъдат изпратени чрез извеждане на HTML страница към User Agent-а, която съдържа HTML форма. Изпращането на формата може да става автоматично, например чрез JavaScript. Атрибутът „action” на формата трябва да съдържа URL адреса на получателя. Всеки чифт ключ-стойност трябва да бъде включен във формата като входен <input> елемент, като ключът се задава на атрибута „name”, а стойността – на атрибута „value”, за да може User Agent-а да генерира съобщение с правилния формат. Формата трябва да съдържа и бутон за изпращане.

При приключване на заявката се изпраща HTTP статус код 200 (ОК) ако тя е била успешна, а ако е била неуспешна OpenID доставчикът трябва да пренасочи User Agent-а към URL адреса, посочен в полето openid.return_to, ако стойността съществува и е валиден URL адрес. В съобщението за грешка се съдържат следните полета:

• ns – удостоверява, че заявката е предназначена за OpenID автентикация.

• mode – съдържа текст „error”

• error – съдържа текст с грешката във вид на обикновен текст.

• contact – адрес за връзка с администратора на сървъра.

• reference - token за референция, например номер на билета за грешка или URL.

В допълнение към тези полета, сървърът може да добави допълнителни уточняващи полета. В случай, че погрешно съобщение е получено от разчитащата страна, сървърът трябва да покаже адекватно съобщение към крайния потребител, че не може да продължи.



3.5. Генериране на подписи

Най-честата употреба на връзките (асоциациите) между OpenID доставчиците и разчитащата страна е като Message Authentication Code (MAC) ключ, използван за да подписва съобщенията за OpenID автентикация. Когато се генерират MAC ключове трябва да се използват препоръките от RFC1750 - Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,”.

При генериране на подпис за съобщение се спазват следните стъпки:

• Определя се списък с ключовете, които да бъдат подписани според съобщението, което трябва да бъде подписано. Списъкът с ключовете трябва да бъде част от съобщението. Самият списък се съхранява като стойност, асоциирана с ключа “openid.signed”. Списъкът представлява изредени ключове, разделени със запетая, като префиксът „openid.” е премахнат от всички ключове. Този алгоритъм е единственият, който е способен да подписва ключове, които започват с “openid.”.

• Обхожда се списъкът с ключовете, които трябва да бъдат подписани в реда, в който са изредени в „openid.signed”. За всеки ключ се открива стойността, чиито ключ е равен на ключа от списъкът с подписани ключове, започващ с префикса „openid.”.

• Конвертира се списъкът с чифтове ключове и стойности в символен низ от байтове.

• Определя се алгоритъма на подписа от вида връзка (асоциация), след което се прилага алгоритъма за разкодиране върху символния низ от байтове от предишната стъпка.

OpenID автентикацията поддържа два вида алгоритми за подписи:

• HMAC-SHA1 – ключ с дължина 160 бита;

• HMAC-SHA256 – ключ с дължина 256 бита.

Препоръчва се използването на HMAC-SHA256 (в случай, че се поддържа).



3.6. Иницииране и откриване

3.6.1. Иницииране

За да инициира OpenID автентикация, разчитащата страна трябва да представи на крайния потребител форма, която има поле за въвеждане на идентификатор, предоставен от потребителя. Полето „name” на формата трябва да съдържа стойността „openid_identifier”, за да може User Agent-ите автоматично да определят, че това е OpenID форма. Този атрибут е важен, за да може инициирането на автентикацията да бъде разчетено от разширенията на потребителските уеб браузъри.

3.6.2. Нормализация

Входните данни от инициирането на крайния потребител трябва да бъдат нормализирани в идентификатор, като се спазват следните правила за привеждане на данните в нормален вид:

• Ако въведеният предоставен от потребителя идентификатор започва с “xri://”, тази част трябва да бъде премахната, за да може XRI адресите да се ползват в тяхната канонична форма.

• Ако първият символ е глобален контекстен XRI символ (тези символи са "=", "@", "+", "$", "!"), това означава, че въведеният идентификатор трябва да бъде разчетен като XRI.

• В противен случай, идентификаторът трябва да бъде разчетен като URL адрес. Ако не съдържа http:// или https://, трябва да се използва http://. Ако URL адресът съдържа фрагментна част, тя трябва да бъде премахната заедно с ограничителния знак #.

• URL идентификаторите трябва да бъдат допълнително нормализирани съгласно RFC3986 (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,”), след което да бъдат отбелязани от разчитащата страна като заявен идентификатор и да бъдат използвани при последващо изискване на автентикация.



3.6.3. Откриване

Откриването е процес, при който разчитащата страна използва идентификатора, за да търси (и открива) нужната информация за иницииране на заявки. OpenID автентикацията има три начина, по които да извършва откриване:

• Ако идентификаторът е XRI, разчитащата страна получава XRDS документ, който съдържа нужната информация.

• Ако идентификаторът е URL, прилага се Yadis протоколът върху него и при успех, резултатът е XRDS документ.

• Ако Yadis протоколът не успее и не е намерен XRDS документ, URL адресът се изпълнява и се извършва HTML-базирано откриване.

При успешно извършване на откриването, разчитащата страна има една или повече групи информация, съдържащата следните полета:

• OpenID краен линк на доставчика;

• Версия на протокола.

В случай, че крайният потребител не е въвел OpenID идентификатор, следната информация също ще бъде достъпна след откриването:

• Заявен идентификатор;

• Локален идентификатор за OpenID доставчика.

В случай, че крайният потребител е въвел OpenID идентификатор, няма да има заявен идентификатор. В този случай за целите на извършването на заявки за OpenID автентикация, стойността „identifier_select” трябва да бъде използвана както за заявен идентификатор, така и като локален идентификатор за OpenID.

3.7. Извършване на връзки (асоциации)

Асоциацията между разчитащата страна и OpenID доставчика създава и споделя тайна парола между тях, която се използва за да се верифицират последователни заявки и протоколни съобщения, като по този начин се намалява броя заявки и се ускорява процеса на автентикация. Препоръчително е разчитащата страна да изисква и



формира асоциациите. Ако разчитащата страна е неспособна да създава и съхранява асоциации се използва алтернативен механизъм за верификация, наречен Stateless mode (без състояние).

Сесията за асоциация се инициира чрез директна комуникация от разчитащата страна към крайния URL адрес на OpenID доставчика, като полето „openid.mode” трябва да съдържа стойността „associate”. Накратко, параметрите при заявката за асоциация са:

• openid.ns – удостоверява, че заявката е свързана с OpenID автентикация.

• openid.mode – съдържа стойността „associate”.

• openid.assoc_type – съдържа препоръчителния тип асоциация. Този тип реално дефинира алгоритъма, който да бъде използван в последващите съобщения.

• openid.session_type – съдържа препоръчителния тип сесия, който представлява метода, използван при криптирането на MAC ключа на асоциацията при преноса на данни.

В допълнение, в случай че типът сесия е "DH-SHA1" или "DH-SHA256" се използват и следните параметри:

• openid.dh_modulus – съдържа ключа, кодиран с btwoc и след това с base64 алгоритъма.

• openid.dh_gen – съдържа стойността, кодирана с btwoc и след това с base64 алгоритъма.

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

• ns – удостоверява, че заявката е свързана с OpenID автентикация.

• assoc_handle – ключът, използван за референция към конкретната асоциация в последващите съобщения.

• session_type – типа на сесията, същия като openid.session_type параметъра от заявката за асоциация. Ако OpenID доставчикът не може или не желае да поддържа този тип, отговорът съдържа маркер за неуспех.



• assoc_type – стойността на openid.assoc_type - ако OpenID доставчикът не може или не желае да поддържа този тип, отговорът съдържа маркер за неуспех.

• expires_in – времето (в секунди), през което конкретната асоциация е валидна. Разчитащата страна не трябва да използва тази асоциация след като това време е изтекло.

• mac_key – споделената парола, използвана за тази асоциация (кодирана с base64 алгоритъм, но не криптирана).

• error – съдържа текст с грешката във формата на обикновен текст (в случай, че отговорът съдържа статус за неуспех). В случай че няма грешка, това поле не съществува, или е с празна стойност.

• error_code – в случай на грешка, съдържа стойност „unsupported-type”, а в случай че няма грешка, стойността му е празна.

Няколко от гореописаните полета съдържат типове за асоциация. Поддържаните типове асоциация са (всеки от тях се нарича с името на алгоритъма, използван за подписване):

• HMAC-SHA1;

• HMAC-SHA256.

Няколко от гореописаните полета съдържат типове за сесията. Поддържаните типове сесия са:

• Сесии без криптиране – при тези сесии OpenID доставчикът изпраща MAC ключа на разчитащата страна под формата на обикновен текст. Това дава възможност на хакер-подслушвач да посрещне и открадне ключа и да създава, и изпраща фалшиви съобщения към разчитащата страна когато не се използва криптиране в транспортиращия слой. Поради тези съображения този вид сесии не трябва да бъдат използвани, освен ако съобщенията не използват криптиране в транспортиращия слой. В допълнение към това, MAC ключът, изпратен от OpenID доставчика трябва да използва правилния алгоритъм, уточнен при извършваният тип асоциация.

• Сесии с криптиране по алгоритъма на Дифи-Хелман - "DH-SHA1" и "DH-SHA256" типовете асоциация използват Дифи-Хелман алгоритъма за подписване за да предават сигурно споделената парола. Разчитащата страна посочва модул p и генератор g. След това разчитащата страна избира произволен частен ключ xa и



OpenID доставчика избира произволен частен ключ xb, като и двата ключа са в интервала [1;p-1]. Споделената парола, използвана за криптиране на MAC ключа се смята по следната формула:

g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p.

3.8. Изискване на автентикация

След като разчитащата страна успешно е извършила откриване и евентуално е създала асоциация с открития краен URL адрес на OpenID доставчика, тя може да изпрати заявка за автентикация към OpenID доставчика, за да получи потвърждение. Заявката за автентикация се изпраща чрез индиректна комуникация и съдържа следните параметри:


• openid.mode – съдържа стойността "checkid_immediate" или "checkid_setup". Ако разчитащата страна иска крайният потребител да взаимодейства директно с OpenID доставчика, трябва да бъде използван “checkid_setup”. Пример за ситуация, в която директното взаимодействие между крайния потребител и OpenID доставчика не е препоръчително е, когато автентикацията се извършва асинхронно чрез JavaScript.

• openid.claimed_id – съдържа заявения идентификатор. Параметрите "openid.claimed_id" и "openid.identity" трябва или да присъстват, или и двата да ги няма в съобщението. Важно е OpenID доставчиците да приемат XRI идентификаторите както с, така и без “xri://” префикса.

• openid.identity – съдържа локалния идентификатор за OpenID доставчика. Ако не е посочен различен локален идентификатор, трябва да се използва заявения идентификатор.

• openid.assoc_handle – ключ, идентифициращ асоциацията между разчитащата страна и OpenID доставчика, който трябва да бъде използван за подписване на отговора.



• openid.return_to – съдържа URL адрес, към който OpenID доставчика трябва да препрати User Agent-а с отговора, показващ статуса на заявката. Тази стойност не е задължителна, като в случай че се пропусне това означава, че разчитащата страна не желае крайния потребител да бъде пренасочван.

• openid.realm – т.нар. област, съдържа URL шаблон, за който OpenID доставчика трябва да поиска потвърждение от крайния потребител. Тази стойност трябва да бъде попълнена задължително, в случай че openid.return_to е празна.

Областите (realms) са URL шаблони, които представят частта от URL адреса, за която заявката за OpenID автентикация е валидна. Областите са създадени, за да предоставят на крайния потребител индикация за обхвата на заявката за автентикация. OpenID доставчиците трябва да представят област, когато изискват потвърждението на крайните потребители за заявка за автентикация. Областта трябва да бъде използвана от OpenID доставчиците, за да идентифицират по уникален начин разчитащите страни. Например, OpenID доставчик може да използва област, за да позволи на крайния потребител да автоматизира одобрението на заявките за автентикация. Областите в общия смисъл са шаблони, подобни на URL със следните разлики:

• областта не трябва да съдържа URI фрагменти;

• областта може да съдържа маскиращ символ в началото на URL адреса. Маската се състои от символите „*.” добавени преди DNS името на домейна.

URL адресите отговарят на дадена област-шаблон, ако:

• URL схемата и портът на URL адреса са идентични на тези в шаблона;

• URL пътят е същия или към поддиректория от пътя на шаблона;

• Домейнът в шаблона съдържа маскиращите символи „*.”, както и крайната част от домейна е идентична с тази на шаблона (последвана от маскиращите символи);

• Домейнът на URL адреса е идентичен с този на шаблона.

Когато openid.return_url е зададен, URL адресът трябва да съвпада с този на параметъра „openid.realm”, или OpenID доставчикът трябва да върне съобщение за грешка при индиректната комуникация. Освен това, препоръчително е OpenID доставчиците да защитават потребителите си от задавайки за шаблони твърде всеобхващащи URL адреси, като например http://*.com или http://*.co.uk/, защото тези



адреси могат да бъдат опасни, когато шаблона се използва за идентифициране на конкретна разчитаща страна.

OpenID доставчиците трябва да потвърждават, че return_url адреса, който е зададен в заявката за автентикация е краен URL адрес на OpenID разчитаща страна. За да потвърди този адрес, OpenID доставчикът трябва да получи крайният URL адрес на разчитащата страна чрез извършване на процеса „откриване”. Както по принцип, когато се извършва откриване, откритият URL адрес е този от последния HTTP отговор (като се следват пренасочванията). Когато откриването завърши, return_url адресът се сравнява с тези на разчитащите страни, получени при резултатите от откриването. Областите могат да съдържат маскиращи символи, при което самият шаблон не представлява валиден URL адрес. В този случай маската се замества с www и върху URL адресът от полученият резултат се извършва откриване. В случай че имат желание, OpenID доставчиците могат да кешират return_to URL адресите, които са одобрени.

Когато се изисква автентикация, разчитащата страна може да поиска OpenID доставчика да не взаимодейства директно с крайния потребител. В този случай доставчикът трябва да отговори незабавно или с потвърждение, че автентикацията е успешна, или с отговор, индикиращ, че заявката не може да бъде завършена без допълнителна намеса на крайния потребител. Това може да бъде постигнато чрез използването на параметъра „openid.mode” – тогава неговата стойност трябва да се настрои да бъде „checkid_immediate”.

3.9. Отговаряне на заявки за автентикация

Когато заявка за автентикация дойде от User Agent-а чрез индиректна комуникация, OpenID доставчикът трябва да определи дали авторизиран потребител се опитва да завърши автентикацията. Ако крайният потребител е авторизиран, доставчикът изпраща потвърждение на разчитащата страна, което служи за доказателство за извършена авторизация.

Ако разчитащата страна поиска идентификатор от доставчика (чрез добавяне на openid.identity параметър към заявката) и има идентификатори, за които крайния потребител е авторизиран да изпраща автентикационни отговори, OpenID доставчика трябва да позволи на крайния потребител да избере кой идентификатор иска да използва.



В случай че разчитащата страна изпрати ключ за дадена асоциация заедно със заявката за автентикация, OpenID доставчикът трябва да опита да намери конкретната асоциация, която отговаря на този ключ. Ако асоциацията липсва или вече е изтекла, доставчикът изпраща „openid.invalidate_handle” параметърът като част от отговора със стойността на „openid.assoc_handle” параметъра, след което продължава все едно не е бил подаден ключ за асоциация. Ако не се посочи ключ за конкретна асоциация, OpenID доставчикът трябва да използва частна асоциация за да подпише отговора. Доставчикът трябва да съхранява тази асоциация и данните за нея и трябва да отговаря на бъдещи заявки за проверка на подписа на отговора чрез директна верификация.

Разчитащите страни трябва да приемат и да потвърдят твърденията за идентификаторите, за които не са изискали автентикация предварително. OpenID доставчиците трябва да използват частни асоциации за подписване на положителните твърдения за автентикация.

В случай, че стойността на „openid.return_to” параметъ ра липсва в заявката, разчитащата страна декларира, че не иска да получи потвърждение за автентикация от доставчика. Това може да бъде полезно при обмен на данни между доставчика и разчитащата страна, когато се използват разширения.

Съобщенията за потвърждение на авторизацията представляват заявки, извършени чрез индиректна комуникация. Тези съобщения съдържат следните параметри:


• openid.mode – съдържа стойността „id_res”.

• openid.op_endpoint – съдържа крайния URL адрес на доставчика.

• openid.claimed_id – съдържа заявения идентификатор.

• openid.identity – съдържа локалния идентификатор за OpenID доставчика.

• openid.return_to – копие на URL адресът, който е изпратен в return_to полето при изпращане на заявката.

• openid.response_nonce – представлява символен низ в рамките на 255 символа, като трябва да е уникален за всяко изпращане на отговор на заявка за автентикация. Този символен низ трябва да започва с локалното време на сървъра и може да съдържа допълнителни ASCII символи, за да бъде низа



уникален. Датата и часът трябва да бъдат форматирани спрямо RFC3339, но със следните допълнителни ограничения:

o времето трябва да бъде във времевата зона UTC;

o не са позволени части от секундата.

• openid.invalidate_handle – попълва се в случай че разчитащата страна е изпратила невалиден ключ за асоциация.

• openid.assoc_handle – ключът, използван за подписване на това потвърждение.

• openid.signed – списък с полетата, подписани с горния ключ, разделени със запетаи.

• openid.sig – сигнатура, изчислена спрямо RFC1750, и след това кодирана с алгоритъма base64.

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

3.10. Потвърждаване на твърденията

Когато разчитащата страна получи положително твърдение, преди да продължи тя трябва да провери следните факти за истинност:

• стойността на “openid.return_to” е същата като URL адресът на текущата заявка;

• информацията, получена от извършване на откритие съвпада с тази, приложена в твърдението;

• това твърдение все още не е прието от този OpenID доставчик със същата “openid.response_nonce” стойност;



• Сигнатурата на твърдението е валидна и всички полета, които трябва да бъдат подписани с нея, са подписани.

Ако всички тези факти се окажат верни, твърдението се одобрява. Ако твърдението съдържа заявен идентификатор, то крайния потребител е автентициран с този идентификатор.

3.10.1. Потвърждаване валидността на return_url

За да се потвърди, че “openid.return_to” съвпада с URL адреса на текущата заявка, първоначално се сравняват URL схемата, домейна и пътя. Ако те съвпадат се сравняват параметрите на заявката в return_to и в текущата заявка. Ако и при тях се получи съвпадение, валидността на return_url се счита за потвърдена.

3.10.2. Потвърждаване на откритата информация

Ако заявеният идентификатор в твърдението е URL адрес, който съдържа фрагмент, този фрагмент, както и символът # не трябва да бъдат използвани за потвърждаване на откритата информация. Ако заявен идентификатор е включен в твърдението, той трябва да бъде открит от разчитащата страна и информацията от заявката трябва да съвпада с тази в извършеното откриване. В допълнение към това, заявеният идентификатор не трябва да бъде идентификатор нa OpenID доставчика. Ако в заявката не е включен заявен идентификатор това означава, че твърдението не е за идентификатор и разчитащата страна не трябва да използва идентификаторът, предоставен от потребителя при текущата OpenID транзакция за автентикация, за да унифицира крайния потребител.

3.10.3. Потвърждаване на nonce кода

За да се предотвратят цикличните атаки, агентът, който проверява подписа следи nonce стойностите, включени в положителните твърдения и никога не позволява повече от веднъж една и съща стойност от същия краен URL адрес на OpenID доставчика. Когато се използва „check_authentication”, доставчика не трябва да изпраща повече от един отговор за успех, който да е асоцииран с конкретен nonce. Когато разчитащата страна проверява подписа по време на твърдението, тя трябва се увери, че то не е било прието със същия nonce и от същия краен URL адрес на



доставчик. Текущото време не трябва да бъде използвано за отказ на заявки, чиито времеви зони са твърде далече от тази на сървъра. За да се предотвратят атаки времето за съхраняване на nonce кодове е ограничено, като колкото по-малко е то, толкова по-голям е шанса да възникне проблем при различни времеви зони.

3.10.4. Потвърждаване на подписите

Ако разчитащата страна пази информация за асоциация с конкретния ключ, зададен в това твърдение, тя трябва да провери подписа върху самото твърдение. Ако твърдението няма зададен ключ на асоциацията, разчитащата страна трябва да изиска потвърждаване на подписа от OpenID доставчика чрез извършване на директна комуникация.

3.10.5. Идентифициране на крайния потребител

Заявеният идентификатор в успешна автентикация трябва да бъде използван от разчитащата страна като ключ за локално съхраняване на информация за крайния потребител. Заявеният идентификатор може да бъде използван като видим от потребителя идентификатор. Когато се показват URL идентификатори, частта с фрагмента (включително символа #) може да бъде премахната.

OpenID доставчиците с големи бази данни от потребители могат да използват фрагментите, за да рециклират URL идентификаторите. Този механизъм позволява рециклираните URL идентификатори без фрагмента да бъдат използвани от крайните потребители при автентикация и от разчитащите страни за целите на извеждането на данни. Разчитащите страни трябва да различават идентификаторите с различни URL схеми. Понеже HTTP и HTTPS URL адресите не са еквивалентни, няма как да възникнат проблеми със сигурността, защото ако хакер придобие HTTP адреса на идентификатора, за да използва HTTPS трябва да премине процедурата откриване.

4. Сигурност в OpenID OpenID е сравнително сигурен протокол за автентициране на потребителите. Той предлага защита на данните във всички стъпки и процедури, като има обособени препоръки за предпазване от различни видове атаки.



4.1. Атаки с подслушване

Има едно конкретно място в OpenID протокола, което е уязвимо към атаки с подслушване, което може да доведе до изтичане на потребителска информация. Проблемът се състои в това, че ако nonce не се провери, подслушващият може да пресрещне успешната автентикация и да я използва за свои цели.

Тази атака може да бъде предотвратена лесно чрез криптиране на данните по време на транспортния мрежови слой на тези връзки. В допълнение към това, ако не се използва TLS, тази атака може да бъде предотвратена и като се проверява nonce докато се изпълнява потвърждаването на протоколното съобщение.

4.2. Man-in-the-middle атаки

Асоциациите предпазват подправянето на подписаните полета от някой, подслушващ между потребителите (т.е. man in the middle), с изключение на откриването, сесиите с асоциации и директната верификация. Променянето на подписани полета без подписаната парола изисква разбиването на MAC кода. Тъй като сигурността в този случай зависи от надеждността на MAC кода е важно той да се избира възможно най-дълъг и непознаваем.

Ако съществува дупка в мрежовата сигурност, подписите на съобщенията няма да бъдат адекватни, защото атакуващият може да се представи за OpenID доставчик и да създаде собствени асоциации. Ако атакуващият може да се намесва в процеса на откриване, той няма нужда да се представя за доставчик, понеже може да посочи който и да е такъв. Освен това, ако атакуващият може да промени информацията, върната по време на откриването чрез заменяне на XRDS документа, няма нужда от man-in-the-middle. Един от начините да се предотврати този вид атака е да се подписва дигитално XRDS документът чрез използване на XMLDSIG (RFC3275).

Използването на SSL сертификати, подписани от надежден орган предотвратява такива атаки чрез верифицирането на DNS резултатите с помощта на сертификата. След като валидността на сертификата е установена, фалшифицирането не е възможно, защото атакуващият трябва да се представи за SSL сървър, а за целта трябва да открадне сертификат, което е значително по-трудно и граничи с невъзможното. Поради тези съображения употребата на SSL сертификат е силно препоръчителна.



4.3. Атаки през User Agent

Под User Agent в OpenID се разбира уеб браузъра на крайния потребител, понеже този протокол се използва интерактивно. Възможно е уеб браузъра на крайния потребител или неговия хост да е заразен със spyware или други вируси, което би ограничило силата на автентикационното твърдение, понеже злонамереният софтуер може да направи невъзможно да се разбере дали автентикацията е направена реално със съгласието на потребителя. Трябва да се има в предвид, че повечето web протоколи и приложения разчитат на сигурността на уеб браузъра и хоста, на който е инсталиран той, така че тази потенциална „дупка” в сигурността е по-скоро генерална, отколкото в OpenID протокола.

Cross-site-scripting (XSS) атаките също могат да имат същия ефект. За най-добра сигурност, OpenID доставчиците не трябва да разчитат на скриптовете. Това позволява на User Agent-ите, които не поддържат скриптове или са ги изключили, да работят правилно с OpenID протокола.

4.4. Съображения за потребителския интерфейс

Разчитащата страна трябва да пренасочва крайния потребител към крайния URL адрес на OpenID доставчика в прозорец от най-високо ниво в браузъра, като всички контроли трябва да се виждат. Това осигурява по-голяма защита за крайния потребител срещу всички сайтове-имитатори (т.е. предотвратява phishing атаките).

OpenID доставчиците трябва да образоват крайните потребители за възможностите от phishing атаки и трябва да предоставят на потребителите средства, с които да превъзмогнат такива атаки, например plugin-и за уеб браузърите, чрез които да се верифицира произхода на крайния URL адрес за автентикация на OpenID доставчика.

4.5. Съображения за HTTP и HTTPS идентификаторите

Както по-рано бе споменато, препоръчителния метод за поемане на крайния потребител е да се препраща от HTTP URL към HTTPS URL адрес. Разчитащите страни никога няма да съхраняват HTTP URL адреса по време на откриването и инициирането



ще последва пренасочването към HTTPS адрес като заявен идентификатор. Крайните потребители, които имат притеснения относно метода с пренасочването могат директно да въвеждат HTTPS адреса при всяка разчитаща страна. Това ще им гарантира, че няма да възникне пренасочване от името на разчитащата страна, което минимизира възможността от подслушване.

4.6. DDoS атаки

DDoS атака (б.пр. - организирана атака за отказ на услуга) е опит даден ресурс, предоставян от компютър-жертва, да бъде направен недостъпен за целевите му потребители. Това действие води до възпрепятстване комуникацията между жертвата и потребителите по такъв начин, че те не могат да я достъпват или използват адекватно.

В OpenID протокола има места, в които злонамерен хакер може да се представи за разчитаща страна и да започне DDoS атака срещу даден OpenID доставчик, понеже няма нищо в протоколните съобщения, което да позволява на доставчика бързо да проверява, че дадена заявка е истинска. DDoS атаката в конкретния случаи се състои в това, че циклично изпълнява изискване на асоциация, автентикация или верификация на подпис.

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

Докато тази атака може да бъде с относително лоши последствия, OpenID доставчиците могат лесно да използват лимитиране, базирано на IP адреси, което да се основава на забрана за повече от определен брой заявки от даден IP адрес. Чрез тази защитна мярка ще се предотврати възможността от успешна DDoS атака. Важно е да се отбележи, че OpenID доставчиците могат да получат информация за IP адресите, които имат забрана като обръщат внимание на полетата „openid.realm” и “openid.return_to” в съдържанието на съобщенията.



5. Заключение С течение на развитието и усложняването на средствата за обмен на информация в интернет, както и широката употреба на потребителски акаунти, се повишава нуждата от оптимизиране на множеството профили и тяхното обединяване, като в същото време се поддържа високо ниво на сигурност и защита на потребителските данни.

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

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

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



6. Използвани източници 1. http://en.wikipedia.org/wiki/OpenID

2. http://wiki.openid.net/

3. http://openid.net/

4. http://openidexplained.com/

5. http://www.w3.org/TR/html401/

6. http://janrain.com/openid-enabled/

7. Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” RFC 1750.

8. Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104.

9. Rescorla, E., “Diffie-Hellman Key Agreement Method,” RFC 2631.

10. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616.

11. Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548.

12. Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 3986.

13. Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02”, XRI_Resolution_2.0.

14. Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0”, XRI_Syntax_2.0.

15. C.E. Shannon. „A Mathematical Theory of Communication.” Bell System Technical

16. Resnick, P., “Internet Message Format.”, RFC 2822.

17. Burr, W., Dodson, D., and W. Polk, Ed., “Electronic Authentication Guideline,”, NIST_SP800-63.

http://en.wikipedia.org/wiki/OpenID�

http://wiki.openid.net/�

http://openid.net/�

http://openidexplained.com/�

http://www.w3.org/TR/html401/�

http://janrain.com/openid-enabled/�

openid - Реферат

Documents