CHAP

CHAP (англ. Challenge Handshake Authentication Protocol) — протокол аутентификации с косвенным согласованием. Является алгоритмом проверки подлинности и предусматривает передачу не самого пароля пользователя, а косвенных сведений о нём. Аутентификация узла выполняется путём трехэтапной процедуры согласования[1][2]. Протокол CHAP широко используется различными поставщиками серверов и клиентов сетевого доступа[3]. Определён в RFC 1994.

Принцип работы

Можно выделить цикл, который состоит из трёх основных частей[1]:

  1. После установления PPP-соединения и одобрения обеих сторон на подключение по CHAP-протоколу аутентификатор отправляет на узел пакет CHAP, имеющий тип Сhallenge (вызов), который содержит в себе открытый ключ.
  2. Узел на основе полученного открытого ключа и своего секрета, вычисляет хеш с помощью алгоритма хеширования MD5 и отправляет пакет CHAP, имеющий тип Response (отклик), содержащий в себе вычисленный хеш.
  3. Аутентификатор сравнивает полученное значение хеша со своим расчётом ожидаемого значения хеша. Если значения совпадают, то проверка подлинности считается успешной. При отличающихся значениях происходит разрыв соединения.

Через различные промежутки времени аутентификатор посылает новый запрос узлу, и шаги 1-3 повторяются[4][5].

Структура пакетов CHAP

В информационное поле пакетов PPP с полем протокола 0xc223 инкапсулируется единственный пакет CHAP, который содержит следующие поля[6][7]:

  • Code (Код). Поле Code длиной один октет идентифицирует тип пакета CHAP и может принимать одно из следующих значений:
  1. Сhallenge (вызов, проверка);
  2. Response (отклик);
  3. Success (успех);
  4. Failure (отказ).
  • Identifier (Идентификатор). Поле Identifier длиной один октет позволяет провести дополнительную идентификацию в зависимости от типа пакета. Участвует в согласовании запроса, ответа и подтверждения.
  • Length (Длина). Поле Length длиной два октета определяет длину пакета CHAP, включая все поля (код, идентификатор, длина и данные).
  • Data (Данные). Длина поля Data равна нулю или более октетов. Содержит данные в формате, определяемом полем кода.

Требования к архитектуре

  1. Длина секрета должна быть не менее 1 октета. Предпочтительно, чтобы секрет был примерно той же длины, что и значение хеша используемой хеш-функции (16 октетов для MD5). Это необходимо, чтобы обеспечить достаточно большой диапазон для секрета, в целях защиты от атак повторного воспроизведения[8].
  2. Каждое значение запроса должно иметь глобальную и временную уникальность и быть полностью непредсказуемым, чтобы злоумышленник не смог обмануть узел предугаданным будущим запросом и отправить ответ аутентификатору[8].

Преимущества

  • CHAP обеспечивает защиту от атак повторного воспроизведения. Достигается подобная защита из-за возрастающего значения идентификатора и переменного значения открытого ключа[9].
  • Метод проверки подлинности основан на том, что аутентификатору и узлу известен секрет, который никогда не посылается по каналу. Именно поэтому CHAP обеспечивает лучшую защиту по сравнению с PAP[9][10].
  • Несмотря на то, что проверка подлинности производится только в одну сторону, CHAP-переговоры можно вести в обоих направлениях c помощью того же секрета, обеспечивая взаимную аутентификацию[2].

Недостатки

  • CHAP требует, чтобы секрет был доступен в открытом (незашифрованном) виде. Необратимо зашифрованные базы паролей не могут использоваться[11].
  • Плохо применим для крупных проектов с большим количеством участников, так как каждый секрет должен храниться на обоих концах канала[9].

См. также

Примечания

  1. 1 2 Nitish Dalal, Jenny Shah, Khushboo Hisaria, Devesh Jinwala. A Comparative Analysis of Tools for Verification of Security Protocols (англ.). — 2010. — P. 785. Архивировано 23 сентября 2017 года.
  2. 1 2 Cisco - PPP CHAP (англ.). Архивировано 24 декабря 2017 года.
  3. Microsoft Technet - CHAP (англ.). Архивировано 24 декабря 2017 года.
  4. W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1996. — P. 2. Архивировано 8 марта 2021 года.
  5. M. W. Youssef, Hazem El-Gendy. Securing Authentication of TCP/IP Layer Two By Modifying Challenge-Handshake Authentication Protocol (англ.) // Advanced Computing: An International Journal. — 2012. — March. — P. 11. Архивировано 24 декабря 2017 года.
  6. W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1996. — P. 6. Архивировано 8 марта 2021 года.
  7. M. W. Youssef, Hazem El-Gendy. Securing Authentication of TCP/IP Layer Two By Modifying Challenge-Handshake Authentication Protocol (англ.) // Advanced Computing: An International Journal. — 2012. — March. — P. 12. Архивировано 24 декабря 2017 года.
  8. 1 2 W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1996. — P. 4. Архивировано 8 марта 2021 года.
  9. 1 2 3 W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1996. — P. 3. Архивировано 8 марта 2021 года.
  10. Microsoft Technet - PAP (англ.). Архивировано 24 декабря 2017 года.
  11. Guy Leduc. Verification of two versions of the Challenge Handshake Authentication Protocol (CHAP) (англ.). — 1999. — February. — P. 1. Архивировано 24 декабря 2017 года.

Литература

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.