Разработка динамических сайтов
SEO услуги
Управление контекстной рекламой

Вход на хостинг

Имя пользователя:*

Пароль пользователя:*

IT-новости

20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла

Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......

подробнее

30.07.2015 Ищем уникальный контент для сайта

Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......

подробнее

11.05.2015 Распространённые ошибки разработчиков сайтов

Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......

подробнее

Эпоксидное двухкомпонентное покрытие для пола icoatings.ru.

Теперь посмотрим, что происходит, если пользователь joeuser (а точнее, принципал joeuser@MYREALM.RU – поле instance для «живых» пользователей обычно не используется) пытается получить доступ к этому серверу. Предполагается, что как клиентская программа telnet, так и telnetd демон собраны с поддержкой Kerberos (обе эти программы входят в дистрибутив Heimdal). Разумеется, как сам сервер, так и пользователь должны быть зарегистрированы в одном и том же секторе Kerberos. Как обычно, сеанс подключения к серверу начинается с того, что пользователь запускает telnet со своим регистрационным именем и именем удаленного компьютера telnet -l joeuser kdc.myrealm.ru. Клиентская программа после этого обращается к KDC с просьбой предоставить для joeuser доступ к хосту kdc.myrealm.ru. Kerberos генерирует по определенным правилам шифровальный ключ (session key) и разыскивает по своей базе данных принципалов joeuser и host/kdc.myrealm.ru, а также их пароли (ключи). Если пароли найдены (в противном случае сеанс заканчивается аварийно – т.к. кто-то из этих двух принципалов не зарегистрирован в секторе Kerberos), Kerberos приступает к генерированию сессионного ключа (session key). С помощью ключа принципала host/kdc.myrealm.ru он шифрует сгенерированный session key вместе с именем пользователя joeuser, потом прилагает к зашифрованному блоку вторую копию того же session key и снова шифрует получившийся билетик с помощью пароля пользователя. После этого пакет отсылается клиентской программе. Если к этому времени пользователь набрал свой пароль и он совпадает с паролем, использованным Kerberos при шифровке, то клиентская программа сумеет расшифровать билетик. Далее, половина билетика (с session key) остается пользователю, а вторая, которая не может быть расшифрована клиентом, поскольку ключ сервера ей неизвестен, пересылается на сервер. Сервер расшифровывает ее с помощью своего ключа и таким образом узнает как session key, так и имя пользователя, что позволяет серверу авторизовать его своими собственными средствами. Заметим, что помимо регистрации в этом случае имеется возможность использовать полученный session key, поскольку в итоге он известен как клиенту, так и серверу, для шифрования сетевого трафика в рамках данной сессии, чем многие приложения и пользуются. Схематически процесс обмена сертификатами показан на рис. 1.

Что еще интересного в используемом Kerberos механизме аутентификации? Дело в том, что Kerberos оказывается еще более параноидальным, чем мы предполагали вначале, т.е. считает ненадежными не только сетевые соединения (ни один из паролей, как вы могли заметить, не передается в открытую по сети), но и клиентский, и даже серверный компьютер. Для каждого из них ключ/пароль партнера так и остается неизвестным – только session key, который для потенциального взломщика интереса не представляет, поскольку используется только в данной сессии. Как известно, безопасность и удобство пользователей вещи взаимоисключающие. Но ученым из МТИ удалось найти удачный компромисс, придумав еще одну замечательную вещь – ticket granting ticket (TGT). Если пытаться переводить этот термин на русский – «билет для выдачи других билетов», что-то вроде единого проездного. Смысл его в том, что пользователь сети проходит полностью процедуру регистрации (с вводом имени и пароля) в своем секторе только один раз, а сертификат, полученный в результате, затем используется клиентскими приложениями как эквивалент пользовательского пароля для получения доступа к сетевым сервисам. Процесс выдачи ТGT ничем не отличается от описанного выше, только в качестве службы, к которой пользователь получает доступ, выступает сам Kerberos – его Ticket Granting Service. После получения TGT записывается в кэш-файл на диске клиентского компьютера и затем по мере надобности извлекается оттуда. В схеме, описанной выше, session-key, закодированный в TGT используется вместо пароля пользователя при шифровании сертификата, предоставляемого для доступа к сетевому ресурсу. И хотя TGT хранится в кэше на диске рабочей станции пользователя, угроза, связанная с его перехватом, не столь уж серьезна, поскольку его действенность ограничена по времени. TGT позволяет организовать в корпоративной сети single sign-on (система единой регистрации) систему. Например, с помощью замены системного login на керберизованный аналог (программа с тем же именем входит в состав Heimdal Kerberos) при входе на рабочую станцию пользователь получает TGT, который затем используется для генерирования билетиков, специфичных для какой-нибудь из сетевых служб.


Предыдущая страницаОглавлениеСледующая страница
 
[001] [002] [003] [004] [005] [006] [007] [008] [009] [010] [011] [012] [013] [014] [015] [016] [017] [018] [019] [020]
[021] [022] [023] [024] [025] [026] [027] [028] [029] [030] [031] [032] [033] [034] [035] [036] [037] [038] [039] [040]
[041] [042] [043] [044] [045] [046] [047] [048] [049] [050] [051] [052] [053] [054] [055] [056] [057] [058] [059] [060]
[061] [062] [063] [064] [065] [066] [067] [068] [069] [070] [071] [072] [073] [074] [075] [076] [077] [078] [079] [080]
[081] [082] [083] [084] [085] [086] [087] [088] [089] [090] [091] [092] [093] [094] [095] [096] [097] [098] [099] [100]
[101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120]
[121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140]
[141] [142] [143] [144] [145] [146] [147] [148]

+7 (831) 413-63-27
ООО Дельта-Технология ©2007 - 2016 год
Нижний Новгород, ул. Дальняя, 17А.
Rambler's Top100