Форум PHP

Когда нужно кодировать пароль в md5? Пользователь вводит пароль в форму наживает отправить и методом POST передаются данные в обработчик, шифровать пароль получится только в обработчике? Не смогут его похитеть передавая его не кодированным после ввода POST-ом в обработчик?

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

гуглить можно по запросу "Частично защищенная авторизация с использованием Javascript MD5 функции"

что за глупость?
___
во первых

Выводы Очевидно, схема имеет больше недостатков, чем преимуществ, именно поэтому она до сих пор не внедрена в ядро Drupal, хотя попытки сделать модуль уже были для Drupal 4.5. Существует модуль для Drupal 5: CRAM. Однако, в немного другой форме эта схема используется в PHPLib, PHPMyAdmin, а также на некоторых сервисах Yahoo(по сведениям с Drupal.org). По-настоящему защищенную авторизацию может обеспечить только зашифрованное соединение (SSL).

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

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

При генерации формы сервер генерирует случайный ключ, который сохраняет в сессию. При каждом запросе формы сервер генерирует новый ключ, что дает обфускацию. Кладем ключ в input.hidden и отдаем клиенту.

На клиенте после нажатия кнопки отправки данных, с содержимым пароля делаем md5JS(input.hidden.value + md5JS(input.password.value)) и эту переменную передаем на сервер вместо пароля.

На сервере по логину достаем из базы хэш пароля, достаем из сессии отправленный с формой ключ, делаем md5(ключ в сессии + хэш пароля) и сравниваем то что получилось на сервере с тем, что пришло с логином. Если результаты идентичны - пользователя авторизовываем, а пароль даже в firebug`e не засветился. Ни что не мешает при этом хранить в базе не хэш пароля, а более защищенную его хэша версию.

Минус подхода только один. Нельзя хранить в базе что либо, что нельзя привести обратно к виду "хэш пароля".

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

P.S. Хорошенько поработав над тем, что хранится в базе вместо пароля, даже успешная sql инъекция не позволит авторизоваться за пользователя. Во всяком случае сразу же. А своевременно узнать о проведенной sql инъекции тоже не особо сложно, даже на обычном хостинге.

И можно спать спокойно.
а вот хренас два :)
про угон сессии представление имеете?
в чем принципиальная разница перехватить пароль или перехватить SID?
и как я уже писал несколько лет назад от хакерского прокси через который перенаправят ваш траффик ничего не спасет, кроме защищенного соединения (которое и то не спасет, а всего лишь осложнит)
так стоит ли игра свечь?
если вы не "банкомат", то достаточно обычного пароля :)

А про антиугон сессии слышали? Какая польза от нерабочего SID?

И что еще за прокси? Как это вы можете прослушать трафик между мной и softtime.ru поясните пожалуйста.

>Как это вы можете прослушать трафик между мной и softtime.ru поясните пожалуйста.
Конкретно ваш трафик, если наш сервер не взломан скорее всего никак, а вот если мы соседи по провайдерам, можно будет попробовать (это уже от раздолбайства администратора провайдера зависит и от того, какое у него оборудование). Сейчас это все стало тяжелее, но пока все еще возможно работать по собственно локальной сети.

А про антиугон сессии слышали?
ссылку в студию...
Как это вы можете прослушать трафик между мной и softtime.ru поясните пожалуйста.

Когда вы набираете адрес, например, http://www.yandex.ru, ваш компьютер определяет,  к какому серверу нужно обратиться. В первую очередь он «просматривает» файл hosts (обычно этот файл находится  в папке C:\WINDOWS\system32\drivers\etc), и, если в нем есть адрес сервера (IP-адрес)  для указанного вами имени, то используется именно он.  Если же подходящей записи нет, то нужный адрес сервера запрашивается у вашего провайдера. вирус меняет содержимое файла hosts, дописывая туда адреса своих серверов так, чтобы они  заменили адрес Яндекса и других популярных интернет-сервисов. В результате вам кажется, что вы видите  страницу Яндекса и работаете с ней,  но на самом деле вы находитесь на сервере злоумышленников.

Ну hosts сейчас только ленивый не контролирует, исправить его незаметно от пользователя довольно проблематично (если он худо-бедно защищается), хотя да, это один из возможных сценариев. Подрубиться можно и посередине цепочки, подсунув свои IP-адреса вместо настоящих, особенно, если вы в локальной сети того же провайдера.

Ха! Я ленивый =)
Не в тему немного.... Щас обнаружил, что у меня hosts весит 170кб и забит пробелами, переводами строк и переводами типа "127.0.0.1 dnl-20.geo.kaspersky.com", все про обновление каспера и все на локалхост.
Не подскажите кто это сделал:
- злоумышленник
- каспер, когда обнаружило что он нелицензионный
- или это просто нужно касперу каким-то образом?

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

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

Можно начать отталкиваться хотя бы от этого. Можно менять идентификатор сессии хоть за каждое обращение. В этом случае нужно не только получить доступ к идентификатору, но еще и успеть использовать его до смены. Еще есть javascript, localStorage, ajax, а с этим всем можно такой контроль клиента нагородить, что и параноики успокоятся.

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

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

Легко угоняется и в любом кафе, где есть wifi, да и вообще где есть wifi, к котороу есть доступ, если без VPN (а это любое кафе). А таким доступом в Интернет пользуется впоне достаточное количество людей.

>Не смогут его похитеть передавая его не кодированным после ввода POST-ом в обработчик?
Могут. За этим и нужен SSL (https://), который позволяет предотвратить такой сценарий просто шифруя весь трафик.

Действительно. Даже если и будет подмена IP домена, то фейковый домен, получив шифрованную по SSL инфу от пострадавшего пользователя не сможет ее использовать, потому что для расшифровки нужен приватный ключ сервера, только он - реальный сервер - может расшифровать белеберду, которая пришла от пользователя

а как использовать SSL (https://) в POST передачи? Я ни разу с SSL не работал...

С кодом ничего специального делать не нужно, нужно просто чтобы у вас был настроен SSL и все действия происходили на страницах с адресами https://, а не просто http:// - все остальное сервер и браузер сделают сами.

если будет настроен SSL весь сайт будет адресам https://?
а где SSL настраивается?

>если будет настроен SSL весь сайт будет адресам https://?
Обычно его настраивают таким образом, что вы можете использовать совместно https и http. Т.е. захотели нешифрованный трафик (его меньше), подставляете в адрес http://, а все ссылки на авторизации, оплаты и т.п., там где вводятся пароли, делаете https://

>а где SSL настраивается?
На уровне виртуального хоста в Apache (ну или како-то другого Web-браузера). Более того, там несколько подходов, можно даже сделать, чтобы под SSL был выделен отдельный виртуальный хост, независимый от основного.

Т.е. захотели нешифрованный трафик (его меньше)
а почему нешифрованного трафика меньше?

Потому что он передается как есть, без шифрации. Если вы шифруется трафик, его всегда получается больше, так как сейчас используются сложные шифры. Простой шифр, когда вы заменяете один символ другим (в этом случае объем не изменяется) - быстро расшифровывается, поэтому нужно шифровать так, чтобы из зашифрованного трафика ничего нельзя было бы извлечь без ключей.