Тип проверки подлинности pap

Тип проверки подлинности pap

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

Это наиболее часто используемый метод аутентификации. Варианты:

Отсутствие проверки имен пользователей и паролей. Некоторые администраторы разрешают доступ к сетям и ресурсам без проверки имен пользователей и паролей.

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

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

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

PAP (Password Authentication Protocol) – протокол аутентификации пароля

CHAP (Challenge Handshake Authentication Protocol) – протокол аутентификации с предварительным согласованием вызова

Данные протоколы наиболее часто применяются для авторизации при использовании протокола PPP.

Протокол PPP используется для удаленного подключения через телефонную сеть и каналы ISDN. Является стандартным протоколом инкапсуляции для транспортировки протоколов сетевого уровня. Пришло на смену протоколу SLIP, допускает шифрование, динамическую IP-адресацию и аутентификацию соединений.

Аутентификация PAP для PPP:

Процесс установления соединения:

1. Удаленный клиент устанавливает связь.

2. Удаленный клиент сообщает серверу доступа о том, что используется протокол PPP.

3. Сервер доступа извещает клиента о применении PAP в ходе этого сеанса связи.

4. Удаленный клиент посылает имя пользователя и пароль в формате PAP.

5. Сервер доступа сравнивает имя пользователя и пароль с сохраненными в базе данными и принимает или отвергает их.

— Имя пользователя/пароль передаются в открытом виде.

Аутентификация CHAP для PPP:

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

Процесс установления соединения:

1. Удаленный клиент устанавливает связь по протоколу PPP.

2. Сервер доступа предлагает удаленному клиенту использовать CHAP.

3. Производится процедура трехходового квитирования, которая состоит из следующих шагов:

— сервер доступа посылает сообщение запроса удаленному клиенту;

— удаленный клиент возвращает значение однонаправленной хэш-функции;

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

CHAP предполагает периодический контроль аутентичности клиента с помощью повторного использования процедуры трехходового квитирования.

MS-CHAP – измененная фирмой Microsoft версия, используемая в системах Windows NT.

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

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

Запись аудита состоит из пар атрибут/значение обычно содержащих: имя пользователя, IP адрес пользователя, имя сервиса, время начала и окончания доступа, объем переданных данных, имя сервера доступа.

Серверы управления доступом

| следующая лекция ==>
Защита удаленного доступа | Локальная и удаленная базы данных управления доступом

Дата добавления: 2014-01-07 ; Просмотров: 5947 ; Нарушение авторских прав?

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Читайте также:  Процессор amd athlon 4 ядра

До сих пор наш скрипт сам выполнял аутентификацию, то есть, вводил имя и пароль в ответ на запросы удалённой стороны. Но PPP предусматривает и свои способы аутентификации — PAP (Password Authentication Protocol) и CHAP (Challenge Handshake Authentication Protocol) и мы можем ими воспользоваться, если удалённая сторона достаточна сообразительна, чтобы не только выдать "login:", но и провести PAP или CHAP аутентификацию.

Нужно заметить, что комбинация FreeBSD+ getty до недавнего времени не была таким сообразительным прибором, но, начиная с getty распознает начальные LCP-кадры PPP-соединения и может вызывать, скажем, pppd, который и решает, что делать дальше. До этого getty умел только выдать этот самый "login:" и приходилось использовать mgetty .

Так как наш скрипт дозвонки больше не будет заниматься аутентификацией, нужно убрать из него имя пользователя "igor", его пароль "1234567" и ошибку аутентификации

Теперь скрипт заканчивает работу сразу же, как получит строку "login:". Отметим, что приглашение "login:" не имеет никакого отношения к PAP и CHAP, и pppd воспринимает его не более, как шум в линии, поэтому вместо этой строки может быть любое другое приглашение провайдера, в крайнем случае, ">".

PAP аутентификация происходит следующим образом — при установлении PPP-соединения удалённая сторона предлагает нам аутентификацию PAP. Мы соглашаемся и затем передаём наше имя и пароль открытом текстом. Если удалённую сторону имя и пароль устраивает, то аутентификация считается успешной. Имена и пароли для PAP хранятся в файле /etc/ppp/pap-secrets . У него должны быть такие права доступа Для нашего случая мы запишем в этот файл:

Формат этой строки таков — наше имя, имя удалённой стороны и пароль. В PAP используется только наше имя и пароль, а имя удалённой стороны "cool" может быть произвольным. В принципе, оно нужно только для того, чтобы pppd мог определить, какой пароль нужно использовать в случае, когда Вы используете одно и то же имя у разных провайдеров, например:

Теперь мы можем звонить провайдеру:

Параметры user igor и remotename cool позволяют однозначно определить, какой пароль использовать при аутентификации, в данном случае это 1234567. Как уже говорилось, параметр remotename необходим только, если мы не можем однозначно выбрать пароль из файла /etc/ppp/pap-secrets . Имя нашей стороны можно также задать с помощью параметра name igor, но параметр user имеет больший приоритет. Заметим, что хотя пароль передаётся в открытом виде, удалённая сторона может хранить пароль в виде результата какой-либо хэш-функции, например, MD5, в качестве параметра которой выступает пароль.

CHAP аутентификация происходит следующим образом — при установлении PPP-соединения удалённая сторона предлагает нам аутентификацию CHAP. Мы соглашаемся, и удалённая сторона высылает нам ключ (challenge), состоящий из случайной последовательности символов, и своё имя. Мы берём наш пароль и присланный ключ и прогоняем их через алгоритм MD5. Получившийся результат высылаем вместе со своим именем. Удалённая сторона, зная наш пароль и высланный её ключ, в свою очередь, проделывает то же самое у себя, и если её результат совпадает с присланным нами, то аутентификация считается успешной. Таким образом, пароль не передаётся в открытом виде, но удалённая сторона должна хранить наш пароль в открытом виде.

Читайте также:  Внешние ssd диски обзор

Имена и пароли для CHAP хранятся в файле /etc/ppp/chap-secrets , права доступа у него должны быть такие же, как для PAP: и формат строк тоже совпадает:

Теперь наша строка для звонка провайдеру выглядит так:

Обратите внимание, что она отличается от PAP только отсутствием параметра remotename. Это объясняется тем, что удалённая сторона сама говорит своё имя, поэтому её имя, записанное в файле /etc/ppp/chap-secrets , не может быть произвольным, как это было в случае с PAP. Даже если Вы зададите параметр remotename, имя, сообщённое удалённой стороной, имеет больший приоритет. Что касается имени нашей стороны, то оно может быть также задано с помощью параметра

Может ли pppd аутентифицировать себя в одних случаях через PAP, а в других — через CHAP ? Ответ — да. При запуске pppd проверяет, как он может аутентифицировать себя, исходя из локального имени и имени удалённой стороны, то есть, есть ли в файлах /etc/ppp/pap-secrets или /etc/ppp/chap-secrets строки с такими именами. И если, скажем, удалённая сторона предлагает CHAP, а pppd не находит пароль в файле /etc/ppp/chap-secrets , то он запросит PAP и если это устраивает удалённую сторону, то аутентификация пройдёт по PAP.

Кроме того, можно указать pppd, чтобы он не соглашался проводить аутентификацию тем или иным способом или же требовал какого-то одного способа с помощью различных комбинаций параметров refuse-pap, refuse-chap, require-pap и require-chap. Раньше эти параметры назывались соответственно -pap, -chap, +pap и +chap.

Протокол CHAP является более защищенным, чем РАР. Он использует трехзвенную процедуру обмена пакетами. Для реализации этой процедуры используется четыре типа пакетов:

Проверка подлинности проводится сразу после завершения фазы установления звена передачи данных и может быть повторена любое количество раз в любое время. После того, как звено передачи данных установлено, проверяющая сторона высылает пакет ВЫЗОВ, который включает в себя некоторую последовательность символов. Проверяемая сторона отвечает пакетом ОТКЛИК, содержащим последовательность, сгенерированную с помощью односторонней хэш-функции из содержащейся в пакете ВЫЗОВ последовательности и локально хранимого пароля. Проверяющая сторона сравнивает эту последовательность с самостоятельно вычисленной по тем же исходным данным. Если значения совпадают, то проверяющая сторона высылает проверяемой пакет ПОДТВЕРЖДЕНИЕ, если нет, то звено передачи данных следует разорвать.

CHAP обеспечивает защиту от повторного использования перехваченных (считанных злоумышленником, получившим физический доступ к линии передачи данных) пакетов. Это достигается путем использования последовательно возрастающего идентификатора и изменения содержащейся в пакетах ВЫЗОВ последовательности. Данный метод аутентификации основан на использовании пароля, который известен обеим сторонам. Он никогда не передается по звену передачи данных, хотя доступен обеим сторонам в незашифрованном виде. Используемый алгоритм требует, чтобы пароль имел длину не менее одного байта. Так как используется односторонняя хэш-функция, то практически невозможно вычислить пароль, даже зная исходные последовательности в пакете ВЫЗОВ и пакете ОТКЛИК.

Последовательность, содержащаяся в пакете ВЫЗОВ, должна быть уникальной (иначе можно было бы повторно использовать перехваченный ранее пакет ОТКЛИК, посланный в ответ на пакет ВЫЗОВ, содержащий ту же самую последовательность, и таким образом сфальсифицировать процедуру) и непредсказуемой (иначе можно было бы, предсказав эту величину, составить пакет ВЫЗОВ и, имитируя проверяющую сторону, послать проверяемой стороне этот пакет, получить и сохранить пакет ОТКЛИК, дождаться использования такого же пакета ВЫЗОВ настоящей проверяющей стороной и послать в ответ полученный “обманным путем” пакет ОТКЛИК).

Читайте также:  Как открыть средство диагностики directx

Процедура аутентификации с помощью протокола CHAP может быть затребована так же, как и в случае с протоколом РАР, только с указанием шестнадцатиричного номера, соответствующего CHAP и метода аутентификации, то есть используемой хэш-функции. Причем стандартной функцией, которая должна поддерживаться во всех реализациях, является MD5 (Message Digest Version 5 – профиль сообщения, версия 5). После этого производится обмен пакетами протокола CHAP. Эти пакеты имеют тот же формат, что и пакеты протокола РАР (рис. 2.3). Поле КОД указывает тип пакета.

Поле ИДЕНТИФИКАТОР содержит уникальное значение, которое позволяет определить, какому запросу соответствует полученный ответ. Поле ДЛИНА содержит длину пакета в байтах. Длина и формат поля ДАННЫЕ определяются типом пакета CHAP.

Процедура аутентификации начинается с отправки проверяющей стороной пакета ВЫЗОВ. Этот пакет должен быть отправлен повторно, если в ответ на него не был получен пакет ОТКЛИК. Кроме того, такой пакет может быть отправлен уже в ходе работы протоколов сетевого уровня для того, чтобы убедиться, что система на противоположной стороне звена передачи данных осталась той же самой.

Поле данных CHAP в пакете ВЫЗОВ содержит:

 произвольную последовательность символов, которая должна быть уникальной для каждого посланного пакета ВЫЗОВ; ее длина зависит от применяемого алгоритма генерации этой последовательности и не зависит от используемой хэш-функции;

 длину последовательности в байтах;

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

Пакет ОТКЛИК должен быть отправлен проверяемой стороной в ответ на каждый принятый пакет ВЫЗОВ. Поле данных CHAP в пакете ОТКЛИК содержит:

 результат вoздeйcтвия односторонней хэш-функции на строку символов, полученную путем конкатенации идентификатора проверяющей стороны из пакета ВЫЗОВ, хранимого локально пароля и последовательности символов из пакета ВЫЗОВ; длина результата зависит от применяемой хэш-функции (16 байт для функции MD5); в случае использования двусторонней (взаимной) аутентификации пароли, используемые для получения результата, не должны совпадать (иначе злоумышленник сможет, получив пакет ВЫЗОВ, отправить его в качестве собственного, получить в ответ пакет ОТКЛИК и отправить его в качестве собственного пакета ОТКЛИК);

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

Получив пакет ОТКЛИК, проверяющая сторона сравнивает содержимое результата из этого пакета с вычисленной самостоятельно на основании тех же исходных данных с помощью той же хэш-функции величиной. В зависимости от результата этого сравнения проверяющая сторона высылает либо пакет ПОДТВЕРЖДЕНИЕ, либо пакет ОТКАЗ. После передачи пакета ОТКАЗ проверяющая сторона разрывает звено передачи данных.

Поле данных CHAP в пакете ПОДТВЕРЖДЕНИЕ и пакете ОТКАЗ содержит:

 сообщение, которое, как правило, содержит текст, содержание которого стандартом не устанавливается;

 длину сообщения в байтах.

Статьи к прочтению:

  • Протокол аутентификации pap
  • Протоколы аутентификации удаленного доступа

Configure PPP with CHAP for the Cisco CCNA

Похожие статьи:

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

Протокол PAP oбecпeчивaeт простейший метод аутентификации. Он использует двухзвенную процедуру обмена пакетами. Эта процедура может отрабатываться только…

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

Ссылка на основную публикацию
Телефон леново включается но не запускается
Бывает, что пользователь включает свой смартфон, процесс доходит до заставки (логотипа) и дальше не грузится. Сразу начинается паника, ведь телефон...
Сфера деятельности интернет провайдера
Может предоставлять услуги: Однако самыми распространенными являются услуги виртуального хостинга, регистрации доменов и VDS. Технические аспекты Задача хостинговой компании —...
Сфинкс вижн форум пользователи
Здравствуйте. Сделал поиск по фильмам. Все работает, но почему то не могу сделать ранжирование поиска. Через апи поставил $sphinx->SetFieldWeights(array ('item_runame'...
Телефон леново инструкция для чайников
Большинство из нас чувствует себя неуверенно, когда приходится знакомиться с новой операционной системой. И несмотря на то, что Андроид сегодня...
Adblock detector