ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Dmitry Radishev                      2:5015/42      10 May 2001  20:16:10
 To : Pavel.Titov@mtu-net.ru
 Subject : PPP
 -------------------------------------------------------------------------------- 
 

 Thursday May 10 2001 10:10, Pavel.Titov@mtu-net.ru wrote to All:
 
  >>  Повторяю: по твоему на диалапе при chap-аутентикации пароли
  >> передаются плэйнтекстом? В таком случае бегом в библиотеку, читать
 
  PT> Хорошо, тогда так: по диалапу пароли могут быть переданы
  PT> плейн-текстом, но что это так - не факт.
 
  А волга впадает в каспийское море. Спрашивали-то про авторизацию на ппп, а не
 про то, как _могут_ быть переданы пароли на диалапе.
 
  >>  >>  PT>  после проверки
  >>  >>  PT> запускается PPP/SLIP/UUCP
  >>  >>  Брр. Это где это после ppp+pap/chap negotiation запускается
 
  PT> Hе после ppp, а вместо. Подробно - в факах на aha.ru, там описано.
 
  Hу да. А лучшая контрацепция - это чашка чая _вместо_.
  Каким боком запускаемый _вместо_ ппп слип или ююпц касается авторизации по
 ппп?
 
  PT> Согласен, тут ошибся. Я об том случае когда идет сначала авторизация
  PT> плейн текстом, потом запуск протокола, запрошенного клиентом.
 
  Принято.
 
  >> имеет отношения к авторизации через ппп. А вот про пап/чап ты как-то
  >> не вспомнил.
  PT> В вопросе было еще о назначении IP. Вот тут dhcp применяется. Или
  PT> может быть применен.
 
  Вопрос терминологии - называть ли передаваемый через ппп адрес "DHCP" или не
 называть. Поскольку обычно dhcp называют вполне конкретный протокол получения
 конфигурации ip в локалке, термин dhcp _обычно_ не используется для ппп. Хотя в
 более общем смысле это тоже некое dhcp, согласен :-)
 
  >> всех говорить - прочитаешь где-нибудь что они значат?
  PT> Дай развернутый ответ на первоначально заданный вопрос и я с радостью
  PT> прочитаю. Сначала ответь сам, а потом критикуй ответы других.
 
  Дам свёрнутый - ибо в глубины не лазил за ненадобностью. Пароль в ppp может не
 проверяться вообще (в том случае, если он уже проверен - логин-скриптом, или на
 выделенной линии, например). Пароль в самом ппп может проверяться двумя
 способами: pap - запрос пароля удаленной строной и отдача пароля нашей стороной
 в виде плайнтекста (запрос и ответ завернуты в соответствующие ppp-фреймы) и
 chap - challenge autentication protocol, когда удаленная сторона посылает нам
 "challenge" - ключ, с которым мы составляем хеш с паролем ("шифруем" необратимым
 образом), мы посылаем response - полученный хеш, удаленная сторона делает то же
 самое и сверяет хеши, если они сошлись - значит, и пароль верен. Перехват
 трафика ничего не даст, поскольку в следующий раз challenge будет другим, а
 оригинальный пароль в канале не бегает и невосстановим по паре
 challenge/response.
  MS придумало свою версию chap, несовместимую со стандартным - MS chap.
 Принципиальных отличий нет, кроме других фреймов и другого алгоритма
 хеширования.
 
  В общих чертах всё.
 All the best //DiBR                        [TEAM ВСЕ МАСТДАЙ] [шестая базовая]
                                                          [http://dibr.nnov.ru]
 
 --- [LPT] LaMerZ PrOfeSsIoNaL TeaM  /member/
  * Origin: under construction (2:5015/42)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор