CHAP (англ. Challenge Handshake Authentication Protocol) — протокол аутентификации с косвенным согласованием. Является алгоритмом проверки подлинности и предусматривает передачу не самого пароля пользователя, а косвенных сведений о нём. Аутентификация узла выполняется путём трехэтапной процедуры согласования[1][2]. Протокол CHAP широко используется различными поставщиками серверов и клиентов сетевого доступа[3]. Определён в RFC 1994.
Можно выделить цикл, который состоит из трёх основных частей[1]:
- После установления PPP-соединения и одобрения обеих сторон на подключение по CHAP-протоколу аутентификатор отправляет на узел пакет CHAP, имеющий тип Сhallenge (вызов), который содержит в себе открытый ключ.
- Узел на основе полученного открытого ключа и своего секрета, вычисляет хеш с помощью алгоритма хеширования MD5 и отправляет пакет CHAP, имеющий тип Response (отклик), содержащий в себе вычисленный хеш.
- Аутентификатор сравнивает полученное значение хеша со своим расчётом ожидаемого значения хеша. Если значения совпадают, то проверка подлинности считается успешной. При отличающихся значениях происходит разрыв соединения.
Через различные промежутки времени аутентификатор посылает новый запрос узлу, и шаги 1-3 повторяются[4][5].
В информационное поле пакетов PPP с полем протокола 0xc223 инкапсулируется единственный пакет CHAP, который содержит следующие поля[6][7]:
- Code (Код). Поле Code длиной один октет идентифицирует тип пакета CHAP и может принимать одно из следующих значений:
- Сhallenge (вызов, проверка);
- Response (отклик);
- Success (успех);
- Failure (отказ).
- Identifier (Идентификатор). Поле Identifier длиной один октет позволяет провести дополнительную идентификацию в зависимости от типа пакета. Участвует в согласовании запроса, ответа и подтверждения.
- Length (Длина). Поле Length длиной два октета определяет длину пакета CHAP, включая все поля (код, идентификатор, длина и данные).
- Data (Данные). Длина поля Data равна нулю или более октетов. Содержит данные в формате, определяемом полем кода.
- Длина секрета должна быть не менее 1 октета. Предпочтительно, чтобы секрет был примерно той же длины, что и значение хеша используемой хеш-функции (16 октетов для MD5). Это необходимо, чтобы обеспечить достаточно большой диапазон для секрета, в целях защиты от атак повторного воспроизведения[8].
- Каждое значение запроса должно иметь глобальную и временную уникальность и быть полностью непредсказуемым, чтобы злоумышленник не смог обмануть узел предугаданным будущим запросом и отправить ответ аутентификатору[8].
- CHAP обеспечивает защиту от атак повторного воспроизведения. Достигается подобная защита из-за возрастающего значения идентификатора и переменного значения открытого ключа[9].
- Метод проверки подлинности основан на том, что аутентификатору и узлу известен секрет, который никогда не посылается по каналу. Именно поэтому CHAP обеспечивает лучшую защиту по сравнению с PAP[9][10].
- Несмотря на то, что проверка подлинности производится только в одну сторону, CHAP-переговоры можно вести в обоих направлениях c помощью того же секрета, обеспечивая взаимную аутентификацию[2].
- CHAP требует, чтобы секрет был доступен в открытом (незашифрованном) виде. Необратимо зашифрованные базы паролей не могут использоваться[11].
- Плохо применим для крупных проектов с большим количеством участников, так как каждый секрет должен храниться на обоих концах канала[9].