А почему бред (2tny2001)

shingrus

Guest
Автор оригинала: Barlone
Ну найди RFC по TCP и внимательно изучи процедуру установки соединения и использование сигнала RST. Здесь форум не по основам TCP/IP.
кроме всего прочего ip пакет содержит ethrnet адрес, правильно? ну так вот перехватили мы то, что ушло от сервера к клиенту, на его запрос авторизации... все обмен закончен... клиент получил ответ смотрит на экран собирается жмыхать кнопку формы с супер секретным хешем,а мы первыми в физ сегменте, сформировали ответ на основе этого хэша, подменили ip на клиента, а ethernet адрес на свой...и всё... можно долго проверять ip, сравнивать хеши
 

Yurik

/dev/null
подменили ip на клиента, а ethernet адрес на свой.
у вас такое получалось проделать на практике (помнится как то мы с этим экспериментировали, ничего не вышло)
 

shingrus

Guest
Автор оригинала: Yurik
у вас такое получалось проделать на практике (помнится как то мы с этим экспериментировали, ничего не вышло)
нет, я говрю о потенциальной возможности, я не пробовал... (я имею ввиду данный алгоритм реализовать) задач таких не стояло...
а у Вас, что ip адрес сменить не вышло? -.)
почему, интересно?
 

Yurik

/dev/null
(Cистема W2k SP2)
потому что выбивало варнинг на компютере жертвы (что-то там обнаружено в сети) и на нашем (IP занят), а на нашем отключало сеть с предложением поменять IP и перезагрузить.
P.S. На Unix наверное побольше возможности, но не пробовали
 

Romantik

TeaM PHPClub
Приветствую. Не было меня- вот приехал, почитал эти бредни.
Ведь уже обсуждали и не раз (Тони уже аж устал и замолчал :) )
Юрик, если я буду сидеть в твоем сегменте, то мне достаточно снифера и телнета, что бы наделать пакостей. И ПОФИГ что ты будешь извращятся с МД5 и ИП
1. ловлю снифом все твои хеши и анализирую
2. телнетом отсылаю ТВОИ хеши обратно подставляя нужные ИП
3. отсоединяю жертву от сети( много способов) и "прикидываюсь" им.
Все это относится к сегменту, а по статистике- наибольшая часть взломов происходит изнутри!
Это все к тому, что SSL придумали не зря.
 

Yurik

/dev/null
1. ловлю снифом все твои хеши и анализирую
телнетом отсылаю ТВОИ хеши обратно
Romantik, ты сначала почитай о чем речь а тогда скажешь как ты это анализировать собираешься а обратно хещи слать. Идентификатор сессии - это пожалуйста, а хеш - зась.
придумали не зря
полностью согласен
 

makRo

Guest
Всё же, этот способ значительно повышает уровень безопасности, по сравнению с открытой отправкой пароля.
 

makRo

Guest
Более того, немного подумав, скажу ещё,
что используя этот способ (немного модифицированный) можно вообще защитить приложение от зловредных действий атакующих (перехватывающих трафик), без использования SSL ))

Данные, конечно, перхватить можно, НО повлиять на поведение приложения и прочитать пароль - нет (если не подбирать хэши). Этого вполне будет достаточно для систем управления контентом.

Суть: Нужно при каждом обращении к серверу менять хэши в сессии и передавать каждый раз хэшированный пароль серверу. Возникает вопрос - если при передаче от клиента пакет перехватят и подменят команду (например $_POST['action']..). В этом случае, можно использовать поддтверждение команд (причём с разными хэшами), т.е. если атакующий может подменить первую команду, то подтверждение, незная пароля, сделать не сможет.

Правда клиента лучше делать на ActiveX или Java...
Вообще это похоже на то как работает авторизация Apache (через .htaccess), только с шифрованием пароля и сменой хэша..

P.S. Если есть аргументы не впользу этой мысли, буду рад выслушать.
 

shingrus

Guest
Автор оригинала: makRo
Суть: Нужно при каждом обращении к серверу менять хэши в сессии и передавать каждый раз хэшированный пароль серверу.
а как менять хеши? пароль-то один? что значит менять хеши и кто это будет делать javascript - тогда алгоритм-то будет передан открытым образом...
смысл... вы так щас договоритесь до ассиметричного шифрования... чтд.
да? а чем клиент на java или activeX лучше - чтобы шифровать поток? и чем это, тогда от ssl В ПРИНЦИПЕ отличается? ну не получится...
 

Yurik

/dev/null
никаких подводных камней я пока не вижу в указанном способе, смущает только одно:
передавать каждый раз хэшированный пароль серверу
такой ход мысли уже меня когда-то посещал, но где клиент (броузер и яваскрипт) будет помнить пароль (не вводить же его каждый раз)
 

makRo

Guest
Автор оригинала: shingrus
а как менять хеши? пароль-то один? что значит менять хеши и кто это будет делать javascript - тогда алгоритм-то будет передан открытым образом...
Ты статью читал ? Вот ещё я тут схемку набросал http://www.galaktika.irk.ru/design/help/s-pass.gif
смысл... вы так щас договоритесь до ассиметричного шифрования... чтд.
да? а чем клиент на java или activeX лучше - чтобы шифровать поток? и чем это, тогда от ssl В ПРИНЦИПЕ отличается? ну не получится...
Это способ для решения "определённой" задачи.
Конечно, если возможность использовать SSL, как серверу так и клиенту, то лучше юзать SSL. Но иногда это невозможно.
Например полгода назад, мне нужно было написать фичу для офисной базы, которая обновляла БД на сервере. Нужно было всего 2-3 запроса. Для этого случая вышеописанный способ подошёл бы, как нельзя кстати. Причём с минимальными затратами. Правда минус - пароль на сервере, можно сказать, хранится в "открытом" виде.

Yurik, именно по причине хранения пароля, я и обратил внимание на что-нибудь типа ActiveX или Java.

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

Yurik

/dev/null
алгоритм-то будет передан открытым образом...
алгоритм MD5 никто не скрывает, это free source.

Вопрос 2 ALL:
Как можно организовать клиентские сессии (типа как по ссылке Barlone) чтобы как минимум NN и Opera тоже прокатывали и желательно без ActiveX и Java.

Возможный ответ:
Создать в javascript куку на заведемо несуществующий домен (чтобы она никуда не посылалась) и потом её читать. Но что-то самому кажется что так сделать ен удастся т.к. она не будет видима в пределах реальной страницы
Возможный ответ 2:
создать hidden frame который не перегружается и в нем установить hidden поле.
 

Yurik

/dev/null
Ответ 3, наиболее верный (если ничего не помогает, прочтите наконец инстрекцию :) )
Set-Cookie: name=value [;EXPIRES=dateValue] [;DOMAIN=domainName] [;PATH=pathName] [;SECURE]

SECURE specifies that the cookie is transmitted only if the communications channel with the host is a secure. Only HTTPS (HTTP over SSL) servers are currently secure. If SECURE is not specified, the cookie is considered sent over any channel.
Все просто, javascript*ом запихиваем в куку все что нам нужно (а нужно только хеш пароля) и ставим опцию SECURE. Т.к. канал незащищенный кука НИКУДА не отсылается (отсылается только в случае https:// но тогда это уже не актуально), но доступна из последующих джаваскриптов.
Метод работает под всеми куки-enabled броузерами.

Теперь о том как будет выглядеть авторизация со случайным меняющимся ключем:
1. На ВСЕ защищенные страницы посылается случайный ключ (в поле хиден), который мы запоминаем в сессии.
2. Страница с javascript на каждой странице берет из куки хеш, соединяет его с ключем из п.1 и вместе с другим (основным) запросом отсылает на сервер.
3. Сервер на КАЖДОЙ защищенной странице сверяет хеши и исполняет скрипт или выбивает.

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

sh

Guest
Автор оригинала: Yurik

Все просто, javascript*ом запихиваем в куку все что нам нужно (а нужно только хеш пароля) и ставим опцию SECURE.
Ломануть локально можно...

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

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

makRo

Guest
Автор оригинала: sh
Автор оригинала: Yurik

Все просто, javascript*ом запихиваем в куку все что нам нужно (а нужно только хеш пароля) и ставим опцию SECURE.
Ломануть локально можно...

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

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

Yurik

/dev/null
>сажусь за комп, заглядываю в куку
время жизни куки ставим 0 и предусматриваем logout. Хранится естественно хеш. Перебрать методом brute force - ваше дело, если хватит жизни, вперед.

Методом "сажусь за комп" и SSL можно взломать, получив сертификат.

2maxRo: если ты занимаешься этой проблемой, пиши на мыло
 

Barlone

Guest
Автор оригинала: Yurik
Все просто, javascript*ом запихиваем в куку все что нам нужно (а нужно только хеш пароля) и ставим опцию SECURE. Т.к. канал незащищенный кука НИКУДА не отсылается (отсылается только в случае https:// но тогда это уже не актуально), но доступна из последующих джаваскриптов.
Метод работает под всеми куки-enabled броузерами.
А ты это тестировал ? Метод интересный, но с ходу непонятно, обязан всегда работать или нет. Проверить надо.
 

makRo

Guest
Автор оригинала: sh
если же запихивать в куки хеш пароля и случайный хэш от сервера уже надежнее, но опять же пароль можно подобрать перебором...
"Случайный хэш от сервера" нет смысла в куку записывать, при вышеописанных способах (можно конечно придумать способ, когда следующий "хэш-команды/пароля" зависит от предыдущего хэша сервера). А md5("пароль") нет смысла подбирать, потому что уже его достаточно, что бы авторизоваться на сервере. Поэтому то, минус этого способа, что "пароль" (md5("пароль")) на сервере хранится в открытом виде, и приемущества хранения зашифрованного пароля на сервере - сходят на нет..

Yurik, правда, нужно это потестить.
Способ предложенный Barlone, немного потестил, работает отлично (домены, по крайней мере, различает), но неизвестно как ведет себя в других "ситуациях".
Эх.. посмотреть бы сырцы експлоера.. :) О ! кто-нибудь работает в гос.учреждениях ? Мелкомягкие коды собираются показать http://www.compulenta.ru/2003/1/15/36833/
http://www.securitylab.ru/?ID=35401&R=0.ML.Violations
 
Сверху