При написании системы защиты для нашего движка я с напарником столкнулся в таком вопросе что будет безопаснее: - авторизация используя протоком SSL - авторизация используя следующий скрипт (код скрипта приведен ниже в урезанном виде) //admin.php PHP: <script src="jquery.js" type="text/javascript"></script> <script src="md5.js" type="text/javascript"></script> <script> function chek(login, passw){ $("#body").load("passwd.php",{user:md5(login) ,passwd:md5(passw)}); } </script> <div id="body"> <form method="POST" enctype="text/plain"> <input type="text" id="user" name="user" value="test" /><br> <input type="password" id="pass" name="pass" value="test2" /><br> <input type="button" value="Проверка2" onclick='chek($("#user").attr("value"), $("#pass").attr("value"));' /> </form> </div> //passwd.php PHP: <? if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER'] == 'http://server/test.php'){ //Тут идет обработка данных }else{ print "Haking alert!"; } ?> И если кто заметит изъян безопастности скрипта посоветуйте?!
Ну в принципе через JavaScript вариант тоже безопасный, т.к. передаются хеши вместо значений... Но всё равно проснифав трафик, злоумышленник будет располагать хешами которые передаются на сервер, наверняка найдётся такая пара логин/пароль, которая подойдёт к аккаунту какого-то нерадивого пользователя. Что касется SSL - то тут хоть до усрачки снифай, ничего о внутреннем содержании канала передачи данных ты не узнаешь... То есть, SSL - верх безопасности... А если вы замутите JavaScript авторизацию через SSL так это вообще чума будет...
как можно вообще сравнивать протокол SSL и проверку паролей на JS?????? это обсалютно разные вещи. А если интересует вопрос безопасности, то стоит организовать процесс передачи хэшей пароля посредством ssl, а далее можно, впринципе, получив сессию привязаную к пользователю его ip и т.д. работать по простому http.
А как это всё на Php сделать? Хочу сделать на сайте возможность регистрации юзеров, для того, чтобы юзеры могли настраивать сайт под свои нужды.
SSL луче конечн но возни с ним та и дороговато будет Вроде как только крутые раскрученные порталы юзают ссл а для середнякового сайта и через js пойдет все зависит насколько конфиденциальны данные
Как можно передавать хэши паролей вместо самих паролей? Это не шифрование данных, потому что серверный обработчик получает ХЭШ, а не ПАРОЛЬ. А это значит, что система не только не защищает вас от прослушки трафика (т.к. в этом случае авторизация не через пароль, а через его хэш), но еще и разрушает основную концепцию безопасности авторизации в системах ограниченного доступа, т.к., имея доступ к базе данных, злоумышленник уже имеет фактически ПАРОЛЬ, а не ХЭШ и может в этих самых системах авторизовываться по нему (если вы конечно не храните в базе данных хэш от хэша, что вообщем никаким образом не умоляет бредовости идеи передавать вместо пароля его md5 отпечаток). SSL или самодельная шифрация (можно с помощью яваскрипт, но в этом случае вас ничто не страхует перед хакером, если он случайно найдет алгоритм шифрации в яваскрипт (а он это сделает, зная страницу авторизации) ), впрочем от целенаправленной просллушки канала на конкретно этот логин/пароль вас вообще ничего не спасет.
Dword, не тупи. Хэш предается вместо пароля лишь для того, что бы сложно было узнать сам пароль, который, коль ты заговорил о КОНЦЕПЦИЯХ БЕЗОПАСНОСТИ, должен быть максимально скрыт и от злоумышлеников и от администрации, в связи с очень частым использованием пользователями одинаковых паролей в разных системах. по поводу твоего высказывания в адресс Ssl просто нечего сказать....
Бред... А ты попробуй. Если канал прослушивается с целью получить конкретно пароль и логин, то злоумышленник имеет понятие и об организации шифрованного канала и обо всех ключах, которыми обменивается клиент и сервер, или может они ими по воздуу перекидываются?
То что пароль заменяется на хэш, нет в этом никакого смысла. Это не шифрация а просто замена одного другим, а если при этом еще и забывать о том, что в базе должен быть хэш пароля, а не он сам и класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности Update: madnet удалил свой пост
Dword, до тебя не доходит для чего в данном случае хэшируются пароли. >если класть туда полученный md5, то это не просто не имеет смысл, но и создает дополнительные угрозы безопасности нука нука, интересно чем же здесь опаснее чем простой пароль ложить в БД?
Видно надо вернуться с небес в реальность и понять что, если у тебя рыжий цвет ника и ты можешь понижать/повышать "репутацию", это вовсе не означает что ты всегда прав и можешь в категоричной форме рассказывать всякий бред/удалять свои сообщения и так далее. Я закончил.
+))) ЛОЛ не хотел тебя радовать раньш времени, но ты тоже можешь понижать/повышать "репутацию" и удалять свои сообщения. Так что давай пожалуйста без оскорблений, а просто говори по теме, если есть что сказать.
Идея хорошая, можно ещё сделать немного подругому PHP: <? $site = 'http://ваш.сайт.ру' //именно в таком формате (без слеша в конце) if(!preg_match('#^'.$site.'(.*)$#i',$_SERVER['HTTP_REFERER'])) { echo('Попробуйте зайти через сайт.'); } else { //если всё ок } ?>
На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию. Лучший способ защитить пароль, это получить у клиента логин, достать из базы пароль, сгенерировать блок рандомных данных длиной примерно 256 байт, передать его клиенту, потом каждый из вас зашифрует его хэшем пароля, сервер положит хэшь в сесионную переменную, Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную. Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения. При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин. При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля. Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип. Новый пароль, при смене пароля можно хэшировать и зашифровать хэшью старого, так как и клиент и сервер её знают.
Гениально! +++ Хотя вклиниться в текущее соединение по прежнему хакеру никто не мешает, если он сможет блокировать легального клиента и имеет возможность посылать пакеты серверу системы ограниченного доступа.
Хотя, ведь можно дальше шифровать трафик настоящим паролем, который теперь знает только клиент и сервер? Вообщем супер. А ты сам придумал?
Такие алгоритмы элементарно придумываются после прочтения книги товарища Шнаера "Прикладная криптография". Думаю, автор с ней знаком. Единственное трезвое сообщение из всего топика кстати (2hidden).
Да, к сожалению, ни с какой криптографической литературой не знаком (что собираюсь в скором времени исправить), поэтому мои посты в этой теме были направлены на указание ошибок(коими я их по прежнему считаю) предыдущих авторов, но ни как не на решение самой проблемы.
