Что такое в роутере pap

В настоящее время, имея доступ к беспроводной сети, многие могут легко получить доступ к важной информации, поэтому важно выбрать правильный тип аутентификации для защиты вашей беспроводной сети. Ниже мы рассмотрим несколько типов протоколов аутентификации и рекомендации по выбору наиболее надежного варианта.

1. Что такое PAP и CHAP
2. Как выбрать тип аутентификации
3. Какие протоколы аутентификации поддерживает PPP
4. Почему медленный интернет на андроиде
5. Советы по защите беспроводной сети
6. Выводы

Что такое PAP и CHAP

PAP и CHAP — это два типа протоколов аутентификации для беспроводной сети. PAP (Password Authentication Protocol) — это основной и наименее защищенный способ аутентификации. Протокол PAP отправляет имя пользователя и пароль в открытом виде и криптографически не защищен, что делает его уязвимым к атакам и различным видам взлома паролей. CHAP (Challenge Handshake Authentication Protocol) более защищенный протокол, потому что он выполняет проверку подлинности внутрисквозной связи между оригинальным запросом и ответом клиента. CHAP чаще используется для безопасных подключений к серверам или VPN-сетям.

Как выбрать тип аутентификации

Наиболее надежным методом аутентификации сейчас считается WPA3, который обеспечивает более надежную защиту, чем WPA2. Однако, старые устройства не всегда поддерживают WPA3, поэтому для лучшей совместимости мы рекомендуем использовать смешанный режим WPA2/WPA3 — Personal. Если вам требуется высокий уровень защиты, выбирайте протокол CHAP.

Какие протоколы аутентификации поддерживает PPP

Microsoft PPP поддерживает следующие NCP:

• Internet Protocol Control Protocol (IPCP) для настройки IP.
• Internetwork Packet Exchange Control Protocol (IPXCP) для настройки IPX.
• AppleTalk Control Protocol (ATCP) для настройки AppleTalk.

Почему медленный интернет на андроиде

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

Советы по защите беспроводной сети

• Используйте более надежный протокол WPA3;
• Обновляйте пароли и логины для доступа к сети;
• Никогда не будьте связаны со слабыми точками доступа, такими как открытые Wi-Fi-сети;
• Никогда не храните личные данные на общедоступной сети без защиты пароля;
• Периодически проверяйте свою сеть на наличие вторжений;
• Установите антивирусное программное обеспечение на все устройства, подключенные к беспроводной сети.

Выводы

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

Время на прочтение
2 мин

Количество просмотров 24K

Как давно интернет провайдеры похоронили PAP? 5, 10, 15 лет назад?

Однако Password Authentication Protocol живее всех живых. Описания и схему выполнения подключения можно найти здесь. Если заглянуть в только вышедшую Windows 10 и попробовать создать там PPPoE подключение, по умолчанию увидим мы там следующую картину:

Аналогичная ситуация и с PPTP:

А ведь выбор протокола аутентификации зависит не от клиента, вам лишь предлагают, соглашаться или нет — решать вам.

Редко в каких инструкциях от провайдера кроме всего прочего идет графа «Безопасность», это если касаться Windows подключений, про всеми любимые Wi-Fi роутеры можно и вовсе забыть.

А между тем на дворе 2015 год. В магазинах продаются девайсы, ценник которых, не превышая 30$, позволяет даже непосвященному стать небольшим городским провайдером.

Шла суббота

Тихий субботний вечер, на экране любимый сериал. Закончилась одна серия и я сидел с предвкушением ожидая последующей, после 5 минут изучения темного экрана своего телевизора я сообразил что — «Кина небудет, интернет закончился».

Rb750 сообщил что PPTP соединение disconnected. Посмотрев количество mac-адресов (47 против обычных 200+) в бридже на котором висит wan интерфейс справедливо сделал вердикт что на трассе до меня у провайдера проблемы с L1, а значит скорой помощи можно не ждать.

У моего городского провайдера весьма интересный способ раздачи логинов: транслит от улицадом-квартира, так например абонент проживающий на улице 40 лет Октября 14 кв 17 получил бы логин 40let14-17. Возникло желание узнать кто страдает вместе со мной?
Поднимаем PPTP сервер на rb750, вешаем на wan IP-адрес шлюза провайдера. Включаем debug,pptp и соседи с надеждой начинают подключатся к нам.

Ох, да сколько же вас! Сначала дружными рядами отстучались разномастные Wi-Fi (TP-LINK, D-Link, Asus и ко) чуть позже в логах я увидел и host-name=HOME-PC.

Однако никому из них подключиться не удалось, что естественно ведь в secrets их имен быть не могло, а уж тем более и паролей.
А что если убрать в настройках PPTP сервера аутентификацию с использованием chap/mschap/mschap2 и оставить только PAP?

Результаты шокировали:

• из 47 хостов авторизации запросили 43.
• из 43 предложений авторизоватся по PAP отказом ответили — 2.
• 41 хост или 87,2% добровольно отдали мне свой логин-пароль.

Раньше было лучше?

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

Конкуренция вынуждает провайдеров накручивать плюшки в личном кабинете. Мой не исключение.

Получив уже известные результаты я 2й раз за 6 лет с момента заключения договора с моим провайдером зашел в личный кабинет. Желания вредить соседям нет, обогащаться за их счет также, поэтому я использовал личные логин/пароль чтобы узнать что мой провайдер может мне предложить:

• лицевой счет;
• паспортные данные;
• номер моб. телефона;
• баланс;
• кредит;
• блокировка;
• перевод;
• отчет по трафику;
• изменение тарифного плана.

По моему этих аргументов для 87% должно быть вполне достаточно чтобы заняться своим подключением и хотя бы выключить PAP?

Содержание

• 1 Что такое PAP?
• 2 Как работает PAP?
• 3 Что такое CHAP?
• 4 Как работает CHAP?
• 5 Как настроить телефон / планшет в режиме CHAP?
• 6 Как увеличить скорость работы интернета?

Рассмотрим отличие этих протоколов и выберем лучший.

Что такое PAP?

Password Authentication Protocol (PAP) — это самый распространенный и быстрый протокол аутентификации, который используется в протоколе PPP.

Как работает PAP?

При подключении клиента к серверу пароль передается в незашифрованном виде. Сервер дает ответ клиенту либо да пароль верный, либо нет. За счет этого PAP работает быстрее. Но некоторые «хакеры» пользуются этой особенностью, устанавливая ретранслятор сигнала от сотовой вышки в близи интересуемого объекта.

Телефон по умолчанию подключается к самому мощному источнику сигнала. В этом случае может оказаться ретранслятор хакеров. Собрав данные, отправленные методом аутентификации PAP, хакеры могут приступить к расшифровке. Как избежать утечки данных рассмотрим далее.

Что такое CHAP?

Challenge Handshake Authentication Protocol (CHAP) — это более современный и надежный протокол аутентификации, использующийся в протоколе PPP.

Как работает CHAP?

Сервер, при попытке подключения клиента, отправляет ему случайную строку (набор цифр и букв). Компьютер / телефон пользователя берет эту строку, добавляет к ней имеющийся пароль и хеширует по алгоритму MD5. Далее хэш отправляется на сервер, который делает то же самое и сравнивает хеши. Если они совпали, значит пароль верный.

В таком случае у злоумышленников, которые собирают данные остается только случайная строка в незашифрованном виде и хеш MD5. Это является главным преимуществом протокола проверки подлинности CHAP перед PAP.

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

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

Как настроить телефон / планшет в режиме CHAP?

Заходим в настройки

• сим карты и мобильные сети
• выбираете свою симку (Мегафон, Би лайн, МТС, ТЕЛЕ 2, Ростелеком)
• точки доступа (APN)
• Megafon internet (своего сотового оператора Beeline, Tele2, MTS, YOTA)
• Тип аутентификации и выбираем CHAP.

Чтобы настройки сохранились нужно нажать кнопку «еще» и «сохранить».

Как увеличить скорость работы интернета?

Можно в этих же настройках пролистать ниже и нажать пункт канал. Здесь снимаем галочку не указано и ставим галочки:

• LTE
• HSPAP
• HSPA
• HSUPA
• HSDPA
• UMTS
• EDGE
• GPRS
• eHRPD

Introduction

Point-to-Point Protocol (PPP) currently supports two authentication protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both are specified in RFC 1334 and are supported on synchronous and asynchronous interfaces.

• PAP provides a simple method for a remote node to establish its identity using a two-way handshake. After the PPP link establishment phase is complete, a username and password pair is repeatedly sent by the remote node across the link (in clear text) until authentication is acknowledged, or until the connection is terminated.

• PAP is not a secure authentication protocol. Passwords are sent across the link in clear text and there is no protection from playback or trial-and-error attacks. The remote node is in control of the frequency and timing of the login attempts.

For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase. For more information on troubleshooting all the PPP phases (LCP, Authentication, NCP), refer to document PPP Troubleshooting Flowchart for a complete flowchart for step-by-step troubleshooting of all related PPP phases and negotiated parameters.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

CHAP is considered to be more secure because the user password is never sent across the connection. For more information on CHAP, refer to Understanding and Configuring PPP CHAP Authentication.

Despite its shortcomings, PAP may be used in the following environments:

• A large installed base of client applications that do not support CHAP

• Incompatibilities between different vendor implementations of CHAP

• Situations where a plaintext password must be available to simulate a login at the remote host

Unidirectional Vs Bi-directional Authentication

As with most types of authentication, PAP supports bi-directional (two way) and unidirectional (one way) authentication. With unidirectional authentication, only the side receiving the call (NAS) authenticates the remote side (client). The remote client does not authenticate the server.

With bi-directional authentication, each side independently sends an Authenticate-Request (AUTH-REQ) and receives either an Authenticate-Acknowledge (AUTH-ACK) or Authenticate-Not Acknowledged (AUTH-NAK). These can be seen with the debug ppp authentication command. An example of this debug at the client is shown below:

*Mar  6 19:18:53.322: BR0:1 PAP: O AUTH-REQ id 7 len 18 from "PAPUSER"

! --- Outgoing PAP AUTH-REQ. We are sending out our username (PAPUSER)and password ! --- to the NAS. The NAS will verify that the username/password is correct. 
*Mar  6 19:18:53.441: BR0:1 PAP: I AUTH-ACK id 7 Len 5

! --- Incoming AUTH-ACK. ! --- The NAS verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete at this point. 
*Mar  6 19:18:53.445: BR0:1 PAP: I AUTH-REQ id 1 Len 14 from "NAS"

! --- Incoming AUTH-REQ from the NAS. This means we now verify the identity of the NAS.

*Mar  6 19:18:53.453: BR0:1 PAP: Authenticating peer NAS

! --- Performing a lookup for the username (NAS) and password.

*Mar  6 19:18:53.457: BR0:1 PAP: O AUTH-ACK id 1 Len 5

! --- Outgoing AUTH-ACK. ! --- We have verified the username/password of the NAS and responded with an AUTH-ACK. ! --- Two-way authentication is complete.

In the above debug output, the authentication was bi-directional. However if unidirectional authentication had been configured, we would only see the first two debug lines.

Configuration Commands

There are three commands required for normal PAP authentication described below:

ppp authentication pap [callin]

The router that the ppp authentication pap command is configured on will use PAP to verify the identity of the other side (peer). This means the other side (peer) must present it’s username/password to the local device for verification.

The callin option says the router that the ppp authentication pap callin command is configured on will only authenticate the other side during an incoming call. For an outgoing call, it will not authenticate the other side. This means the router initiating the call does not require a request for authentication (AUTH-REQ) from the other side

The following table shows when to configure the callin option:

Authentication Type	Client (calling)	NAS (called)
Unidirectional	ppp authentication pap callin	ppp authentication pap
Bi-directional	ppp authentication pap	ppp authentication pap

username <username> password <password>

This is the username and password used by the local router to authenticate the PPP peer. When the peer sends its PAP username and password, the local router will check whether that username and password are configured locally. If there is a successful match, the peer is authenticated.

Note: The function of the username command for PAP is different than its function for CHAP. With CHAP, this username and password are used to generate the response to the challenge, but PAP only uses it to verify that an incoming username and password are valid.

For one-way authentication, this command is only required on the called router. For two-way authentication this command is necessary on both sides.

PPP pap sent-username <username> password <password>

Enables outbound PAP authentication. The local router uses the username and password specified by the ppp pap sent-username command to authenticate itself to a remote device. The other router must have this same username/password configured using the username command described above.

If you are using one-way authentication, this command is only necessary on the router initiating the call. For two-way authentication this command must be configured on both sides.

Configuration Example

The following configuration sections show the necessary PAP commands for a one way authentication scenario.

Note: Only the relevant sections of the configuration are shown.

Calling Side (Client) Configuration

interface BRI0

! --- BRI interface for the dialout.

 ip address negotiated
 encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

 dialer string 3785555 class 56k

! --- Number to dial for the outgoing connection.

 dialer-group 1
 isdn switch-type basic-ni
 isdn spid1 51299611110101 9961111
 isdn spid2 51299622220101 9962222
 ppp authentication pap callin

! --- Use PAP authentication for incoming calls. ! --- The callin keyword has made this a one-way authentication scenario. ! --- This router (client) will not request that the peer (server) authenticate ! --- itself back to the client. 
 ppp pap sent-username PAPUSER password 7 <deleted>

! --- Permit outbound authentication of this router (client) to the peer. ! --- Send a PAP AUTH-REQ packet to the peer with the username PAPUSER and password. ! --- The peer must have the username PAPUSER and password configured on it.

Receiving Side (Server) Configuration

username PAPUSER password 0 cisco

! --- Username PAPUSER is the same as the one sent by the client. ! --- Upon receiving the AUTH-REQ packet from the client, we will verify that the ! --- username and password match the one configured here.

interface Serial0:23

! --- This is the D-channel for the PRI on the access server receiving the call.

 ip unnumbered Ethernet0
 no ip directed-broadcast
 encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

 dialer-group 1
 isdn switch-type primary-ni
 isdn incoming-voice modem
 peer default ip address pool default
 fair-queue 64 256 0
 ppp authentication pap

! --- Use PAP authentication for incoming calls. ! --- This router (server) will request that the peer authenticate itself to us. ! --- Note: the callin option is not used as this router is not initiating the call.

Debug Outputs

To debug a PPP PAP issue use the debug ppp negotiation and debug ppp authentication commands. There are two main issues that you must watch out for:

1. Do both sides agree that PAP is the method of authentication?

2. If so, does the PAP authentication succeed?

Refer to the debugs below for information on how to properly answer the these questions. Also, please refer to Understanding debug ppp negotiation Output for an explanation of all the different debugging lines with their relative meaning during the different PPP phases, including PPP authentication. This document is useful in quickly determining the cause of PPP negotiation failures. For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase.

Calling Side (client) debug for a successful one-way PAP authentication

maui-soho-01#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-soho-01#ping 172.22.53.144

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.53.144, timeout is 2 seconds:

*Mar  6 21:33:26.412: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  6 21:33:26.432: BR0:1 PPP: Treating connection as a callout
*Mar  6 21:33:26.436: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar  6 21:33:26.440: BR0:1 PPP: No remote authentication for call-out

! --- The client will not authenticate the server for an outgoing call. ! --- Remember this is a one-way authentication example. 
*Mar  6 21:33:26.444: BR0:1 LCP: O CONFREQ [Closed] id 82 Len 10
*Mar  6 21:33:26.448: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1A7C63)

! --- Outgoing CONFREQ (CONFigure-REQuest). ! --- Notice that we do not specify an authentication method, ! --- since only the peer will authenticate us. 
*Mar  6 21:33:26.475: BR0:1 LCP: I CONFREQ [REQsent] id 13 Len 14
*Mar  6 21:33:26.479: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- Incoming LCP CONFREQ (Configure-Request) indicating that ! --- the peer(server) wishes to use PAP. 
*Mar  6 21:33:26.483: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.491: BR0:1 LCP: O CONFACK [REQsent] id 13 Len 14
*Mar  6 21:33:26.495: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the outgoing LCP CONFACK (CONFigure-ACKnowledge) indicating that ! --- the client can do PAP.

*Mar  6 21:33:26.499: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.511: BR0:1 LCP: I CONFACK [ACKsent] id 82 Len 10
*Mar  6 21:33:26.515: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1.A7C63)
*Mar  6 21:33:26.519: BR0:1 LCP: State is Open

! --- This shows LCP negotiation is complete.

*Mar  6 21:33:26.523: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]

! --- The PAP authentication (by the peer) begins.

*Mar  6 21:33:26.531: BR0:1 PAP: O AUTH-REQ id 20 Len 18 from "PAPUSER"

! --- The client sends out a PAP AUTH-REQ with username PAPUSER. ! --- This username is configured with the ppp pap sent-username command. 
*Mar  6 21:33:26.555: BR0:1 PAP: I AUTH-ACK id 20 Len 5

! --- The Peer responds with a PPP AUTH-ACK, indicating that ! --- it has successfully authenticated the client.

Called Side (server) debug for a successful one-way PAP authentication

maui-nas-06#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-nas-06#
*Jan  3 14:07:57.872: %LINK-3-UPDOWN: Interface Serial0:4, changed state to up
*Jan  3 14:07:57.876: Se0:4 PPP: Treating connection as a callin

! --- Since the connection is incoming, we will authenticate the client.

*Jan  3 14:07:57.876: Se0:4 PPP: Phase is ESTABLISHING, Passive Open
*Jan  3 14:07:57.876: Se0:4 LCP: State is Listen
*Jan  3 14:07:58.120: Se0:4 LCP: I CONFREQ [Listen] id 83 Len 10
*Jan  3 14:07:58.120: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFREQ [Listen] id 13 Len 14
*Jan  3 14:07:58.124: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- Outgoing CONFREQ (Configure-Request) ! --- use PAP for the peer authentication.

*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFACK [Listen] id 83 Len 10
*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.172: Se0:4 LCP: I CONFACK [ACKsent] id 13 Len 14
*Jan  3 14:07:58.172: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the incoming LCP CONFACK (Configure-Acknowledge) indicating that ! --- the client can do PAP.

*Jan  3 14:07:58.172: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.172: Se0:4 LCP: State is Open
*Jan  3 14:07:58.172: Se0:4 PPP: Phase is AUTHENTICATING, by this end

! --- The PAP authentication (by this side) begins.

*Jan  3 14:07:58.204: Se0:4 PAP: I AUTH-REQ id 21 Len 18 from "PAPUSER"

! --- Incoming AUTH-REQ from the peer. This means we must now verify ! --- the identity of the peer.

*Jan  3 14:07:58.204: Se0:4 PPP: Phase is FORWARDING
*Jan  3 14:07:58.204: Se0:4 PPP: Phase is AUTHENTICATING
*Jan  3 14:07:58.204: Se0:4 PAP: Authenticating peer PAPUSER

! --- Performing a lookup for the username (PAPUSER) and password.

*Jan  3 14:07:58.208: Se0:4 PAP: O AUTH-ACK id 21 Len 5

! --- This shows the outgoing AUTH-ACK. ! --- We have verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete.

Troubleshooting PAP

When troubleshooting PAP, answer the same questions shown in the Debug Output Section:

1. Do both sides agree that PAP is the method of authentication?

2. If so, does the PAP authentication succeed?

For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase.

The two sides do not agree on PAP as the authentication protocol

In certain configuration you may observe that the two sides do not agree on PAP as the authentication protocol or instead agree on CHAP (when you wanted PAP). Use the following steps to troubleshoot such issues:

1. Verify that the router receiving the call has one of the following authentication commands

   ppp authentication pap
          or 
   ppp authentication pap chap 
          or 
   ppp authentication chap pap
   

2. Verify that the router making the call has ppp authentication pap callin configured.

3. Verify that the calling side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the receiving router.

4. Configure the command ppp chap refuse in interface configuration mode on the calling router.

   Cisco routers will, by default, accept CHAP as the authentication protocol. In a situation where the client wishes to do PAP but the access server can do PAP or CHAP ( ppp authentication chap pap configured), the ppp chap refuse command can be used to force the client to accept PAP as the authentication protocol.

   maui-soho-01(config)#interface BRI 0
   maui-soho-01(config-if)#ppp chap refuse
   

PAP Authentication Does not Succeed

If the two sides agree on PAP as the authentication protocol, but the PAP connection fails, it is most likely a username/password issue.

1. Verify that the calling side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the receiving router.

2. For two-way authentication, verify that the receiving side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the calling router.

   When doing two-way authentication, if the command ppp pap sent-username username password password were not present on the receiving router and the PPP client attempts to force the server to authenticate remotely, the output of debug ppp negotiation (or debug ppp authentication) would indicate

   *Jan  3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials.  Username maui-nas-06

   This error message is an indication of a configuration issue and not necessarily a security breach.

3. 3. Verify that the username and password, matches the one configured in the command ppp pap sent-username username password password on the peer.

   If they do not match you see this message:

   *Jan  3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"
   *Jan  3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING
   *Jan  3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING
   *Jan  3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER
   *Jan  3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is
    "Password validation failure"
   
   ! --- This is an outgoing AUTH-NAK. This means that the mismatch occurred ! --- on this router. Verify that the username and password configured locally is ! --- identical to that on the peer.
   
   

Related Information

• Configuring Authentication
• PPP Troubleshooting Flowchart
• Troubleshooting PPP (CHAP or PAP) Authentication
• Understanding debug ppp negotiation Output
• PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands
• Dialup Technology: Overviews and Explanations
• Technical Support & Documentation — Cisco Systems

From Wikipedia, the free encyclopedia

Password Authentication Protocol (PAP) is a password-based authentication protocol used by Point-to-Point Protocol (PPP) to validate users.^[1] PAP is specified in RFC 1334.

Almost all network operating systems support PPP with PAP, as do most network access servers. PAP is also used in PPPoE, for authenticating DSL users.

As the Point-to-Point Protocol (PPP) sends data unencrypted and «in the clear», PAP is vulnerable to any attacker who can observe the PPP session. An attacker can see the users name, password, and any other information associated with the PPP session. Some additional security can be gained on the PPP link by using CHAP or EAP. However, there are always tradeoffs when choosing an authentication method, and there is no single answer for which is more secure.

When PAP is used in PPP, it is considered a weak authentication scheme. Weak schemes are simpler and have lighter computational overhead than more complex schemes such as Transport Layer Security (TLS), but they are much more vulnerable to attack. While weak schemes are used where the transport layer is expected to be physically secure, such as a home DSL link. Where the transport layer is not physically secure a system such as Transport Layer Security (TLS) or Internet Protocol Security (IPsec) is used instead.

Other uses of PAP[edit]

PAP is also used to describe password authentication in other protocols such as RADIUS and Diameter. However, those protocols provide for transport or network layer security, and therefore that usage of PAP does not have the security issues seen when PAP is used with PPP.

Benefits of PAP[edit]

When the client sends a clear-text password, the authentication server will receive it, and compare it to a «known good» password. Since the authentication server has received the password in clear-text, the format of the stored password can be chosen to be secure «at rest». If an attacker were to steal the entire database of passwords, it is computationally infeasible to reverse the function to recover a plaintext password.

As a result, while PAP passwords are less secure when sent over a PPP link, they allow for more secure storage «at rest» than with other methods such as CHAP.

Working cycle[edit]

PAP authentication is only done at the time of the initial link establishment, and verifies the identity of the client using a two-way handshake.

1. Client sends username and password. This is sent repeatedly until a response is received from the server.
2. Server sends authentication-ack (if credentials are OK) or authentication-nak (otherwise)^[2]

PAP packets[edit]

Description	1 byte	1 byte	2 bytes	1 byte	Variable	1 byte	Variable
Authentication-request	Code = 1	ID	Length	Username length	Username	Password length	Password
Authentication-ack	Code = 2	ID	Length	Message length	Message
Authentication-nak	Code = 3	ID	Length	Message length	Message

PAP packet embedded in a PPP frame. The protocol field has a value of
C023 (hex).

Flag	Address	Control	Protocol (C023 (hex))	Payload (table above)	FCS	Flag

See also[edit]

• SAP – Service Access Point

Notes[edit]

References[edit]

• Lloyd, Brian; Simpson, William Allen (1992). «Password Authentication Protocol». PPP Authentication Protocols. IETF. p. 2. doi:10.17487/RFC1334. RFC 1334. Retrieved 16 July 2015.