Форум PHP

Добрый день!
Вопрос в следующем:

Есть форма авторизации

<form action="handler.php" metod="post"> <input type="text" name="login"> <input type="password" name="password"> </form>

Вместо post может быть и get, это неважно.

login и password передаются по незащищенному каналу и их можно перехватить.
Насколько это опасно?
Нужно ли усложнять процесс авторизации (например на стороне клиента хешировать или еще как нибудь)?
Просто сегодня этот вопрос задали, я и задумался.

например на стороне клиента хешировать
А смысл? подумайте чем отличается перехваченный хеш от перехваченного пароля?
___
Ответ: ничем.

Отличия есть.
Если процедура вычисления хеша занимает ощутимое время, и пароль не самый тривиальный, то отличия эти проявляются не только в теории.

скрипту на сервере абсолютно всё равно что из перехваченного вы ему передадите
настроен на приём пароля - хватайте пароль и отправляйте
настроен на приём хеша - хватайте хешь и отправляйте
о каком ощутимом времени идёт речь?)

>скрипту на сервере абсолютно всё равно что из перехваченного вы ему передадите

Это смотря какому скрипту.

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

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

а) Как Вы в этом процессе перехватите хеш пароля?
б) Чем Вам поможет перехваченный ответ клиента?

1) сколько скриптов с реализацией такого алгоритма на этом форуме?
2) на самом деле перехват не ограничивается одним паролем, хакер может весь трафик прогнать через свой прокси, в итоге конечный скрипт будет работать с IP прокси, а для клиента будет всего лишь видимость того что сценарий нуждается в хеше клиента.
Лучший способ защититься от хакера - быть ему абсолютно ненужным.

1) Чихать я хотел на то, сколько на этом форуме идиотов, некондиционного кода. Главное самому им не стать его не плодить.
Вопросы кошерности форума - к его владельцу.

2) допустим хакер гонит вышеописанный сеанс через свой прокси.
Как он будет аутентифицироваться в следующий раз?

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

Как он будет аутентифицироваться в следующий раз?
обычно хватает одного раза ;)
да и что мешает? если хакер имеет все данные как от клиента так и от сервера и может делать с ними всё что захочет.. для сервера хакер является клиентом (и сервер понятия знать не знает о существовании какого-то настоящего клиента), для клиента хакер является сервером (и клиент в свою очередь думает что "всё хорошо")
В одной из книг на эту тему написано около 20 страниц, а вывод один использовать защищённое соединение для конфиденциальных данных, которое тоже не гарантирует 100% защиты, но на расшифровку перехваченного трафика нужно будет "потратиться".

как страшно жить...

можно детей пугать взамест бабаев и прочей нечисти в которую давно уже никто не верит...

Просто хочу не упустить это из вида.

>Вместо post может быть и get, это неважно.

Это важно.

Я к тому спросил, что ни разу не встречал такой схемы авторизации (в cms-ках которые пробовал разбирать). Везде параметры передаются в открытом виде. Если опытные разработчики не посчитали нужным как то защищать эти данные, я им доверяю. Просто хочется знать почему.

Можно как-нибудь post посланные данные перехватить, а потом самому составить такой же точно post запрос (даже если md5 какой нибудь передается) и авторизироваться под чужим логином?

хочешь усложнить перехват, используй HTTPS