Меню
Что нового?

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

  • Автор темы Автор темы Yurik
  • Дата начала Дата начала
Автор оригинала: Barlone
Ну найди RFC по TCP и внимательно изучи процедуру установки соединения и использование сигнала RST. Здесь форум не по основам TCP/IP.
Нажмите для раскрытия...
кроме всего прочего ip пакет содержит ethrnet адрес, правильно? ну так вот перехватили мы то, что ушло от сервера к клиенту, на его запрос авторизации... все обмен закончен... клиент получил ответ смотрит на экран собирается жмыхать кнопку формы с супер секретным хешем,а мы первыми в физ сегменте, сформировали ответ на основе этого хэша, подменили ip на клиента, а ethernet адрес на свой...и всё... можно долго проверять ip, сравнивать хеши
 
подменили ip на клиента, а ethernet адрес на свой.
Нажмите для раскрытия...
у вас такое получалось проделать на практике (помнится как то мы с этим экспериментировали, ничего не вышло)
 
Автор оригинала: Yurik
у вас такое получалось проделать на практике (помнится как то мы с этим экспериментировали, ничего не вышло)
Нажмите для раскрытия...
нет, я говрю о потенциальной возможности, я не пробовал... (я имею ввиду данный алгоритм реализовать) задач таких не стояло...
а у Вас, что ip адрес сменить не вышло? -.)
почему, интересно?
 
(Cистема W2k SP2)
потому что выбивало варнинг на компютере жертвы (что-то там обнаружено в сети) и на нашем (IP занят), а на нашем отключало сеть с предложением поменять IP и перезагрузить.
P.S. На Unix наверное побольше возможности, но не пробовали
 
Приветствую. Не было меня- вот приехал, почитал эти бредни.
Ведь уже обсуждали и не раз (Тони уже аж устал и замолчал :) )
Юрик, если я буду сидеть в твоем сегменте, то мне достаточно снифера и телнета, что бы наделать пакостей. И ПОФИГ что ты будешь извращятся с МД5 и ИП
1. ловлю снифом все твои хеши и анализирую
2. телнетом отсылаю ТВОИ хеши обратно подставляя нужные ИП
3. отсоединяю жертву от сети( много способов) и "прикидываюсь" им.
Все это относится к сегменту, а по статистике- наибольшая часть взломов происходит изнутри!
Это все к тому, что SSL придумали не зря.
 
1. ловлю снифом все твои хеши и анализирую
телнетом отсылаю ТВОИ хеши обратно
Нажмите для раскрытия...
Romantik, ты сначала почитай о чем речь а тогда скажешь как ты это анализировать собираешься а обратно хещи слать. Идентификатор сессии - это пожалуйста, а хеш - зась.
придумали не зря
Нажмите для раскрытия...
полностью согласен
 
Всё же, этот способ значительно повышает уровень безопасности, по сравнению с открытой отправкой пароля.
 
Более того, немного подумав, скажу ещё,
что используя этот способ (немного модифицированный) можно вообще защитить приложение от зловредных действий атакующих (перехватывающих трафик), без использования SSL ))

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

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

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

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

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

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

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

Возможный ответ:
Создать в javascript куку на заведемо несуществующий домен (чтобы она никуда не посылалась) и потом её читать. Но что-то самому кажется что так сделать ен удастся т.к. она не будет видима в пределах реальной страницы
Возможный ответ 2:
создать hidden frame который не перегружается и в нем установить hidden поле.
 
Ответ 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. Сервер на КАЖДОЙ защищенной странице сверяет хеши и исполняет скрипт или выбивает.

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

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

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

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

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

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

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

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

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

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