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

Если сайт не связан с деньгами, то никаких супер приемов для обеспечения безопасности не нужно, достаточно только 
mysql_real_escape_string

Иначе, нужно включить мозг и подумать.

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

2) При регистрации, если пользователь сам выбирает пароль, проверять не слишком ли простой пароль, и если это так, 
то просить ввести другой, более сложный.

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

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

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


4) При успешной авторизации пользователя. Рассчитать переменную хэшь и поместить ее в массив $_SESSION


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

Для этого мы опять вычисляем хешь, и если он не совпадает с тем, который записан в $_SESSION['hesh'], то просим его ввести пароль и имя пользователя еще раз. 


Это очень сильно повысит безопасность, по сравнению с обычный авторизацией через сессию, 
но тем не менее не обеспечит 100% безопасности, т.к. информацию, которая лётает по проводам, можно при очень огромном
желении перехватить.

5) Для этого остаётся последний метод борьбы - шифрование. Т.е. нужно организовать шифрование информации между браузером и сервером. Все серьёзные организации, связанные с деньгами делают это в обязательном порядке. Втроенный в браузеры алгоритм ширования называется SSL.


В заключение, еще раз повторю, что все это нужно только тогда, если речь идет о чем то действительно серьёзном. Иначе же, можно не парить мозг и спокойно ограничится только первыми тремя пунктами. 








Это сообщение отредактировал(а) NLspieler - 5.2.2010, 00:10

К сожалению не могу, поскольку никогда не занимался поиском таких статей.

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


пруф чего?  примера выше недостаточно?
Ты только что получил значение из базы где логин был условием.
Ты надеешься что полученное значение будет отличаться от логина в условии запроса?  Или как?
Пароль у тебя хранится в открытом виде что тоже не есть хорошо.
Абсолютно не проверяется, а есть ли что-то вообще в $_POST - что неправильно, в отличии кода того же топикстартера. 

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

NLspieler, 



Зачем куда либо писать пароль (или его хешь) ?



ip может быть динамическим, идентификатор браузера подделать очень просто.   Так что ИМХО пункт 4 бессмысленный. 




А вообще - желательно не забывать про существование ООП и MVC. Ни того ни другого нет ни в одном примере упомянутом в этой теме.

Смысл таки определенный есть. Это еще одна дополнительная помеха взломщику.


Эм?
Каким образом это относится к безопасности авторизации? 

При динамическом ip пользователя будет периодически выкидывать . Оно надо? 

Ну а информация о браузере не дает никакой доп защиты.



Разделяй и властвуй.   

Все должно быть отдельно - работа с БД в одном месте, валидация в  другом, а отображение в третьем.  Это позволяет контролировать код, уменьшает его избыточность, позволяет разделять работу между разными людьми.

Как следствие, меньше ошибок - меньше уязвимостей.

Это зависит от требований задачи.



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

Но к теме топика это относится опосредованно.

Лучше что-бы выкидывало, чем пользователя взломали.))
______________

У меня следующий подход, как вам?

Simpliest, 



Да нет - напрямую.  Человек учится, так пускай учится мыслить объектно, пускай учится разбивать приложение на слои.

Идеология должна быть примерно такой:

Есть сущность пользователя. Класс UserEntity cо свойствами id, userName, userHashPasswd, userEMail.....
Есть DAO в котором осуществляется вся работа с БД связанная с юзером. Класс UserDao с методами saveUser(), getUserById, getUserByName, getUserByNameAndPasswd.....

Есть классы контроллеров (контроллер для регистрации пользователя, контроллер для логина).

Могут быть командные объекты для представления POST запросов в виде объектов. Вспомогательные классы (валидаторы и тд....)

Могут быть менеджеры, но для начала можно и без них.

Добавлено через 7 минут и 14 секунд


Ок. Давай посмотрим когда человек может получить id сессии. Тогда когда он либо имеет доступ к компьютеру, а соответственно и к его браузеру и к его ip.

Или когда он мониторит трафик. А соответственно в данном случае он может спокойно отмониторить и пароль. Особенно, если его придется вводить часто.

Защита тут только шифрование канала.

а что же тогда делать? надо все на сервере хранить.
Весь канал что-ли шифровать?

Это сообщение отредактировал(а) Spiker - 5.2.2010, 02:23

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

Spiker, 
Уже писали, для особо тяжелых случаев используется SSL

Но в особо тяжелых случаях и это не панацея 

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

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



Ну слава богу, что только 4 пункт бессмысленный, 
хотя на самом деле он не такой и беесмысленный.

Проведем такой мысленный эксперимент.

Есть сервер, есть взломщик, есть жертва, которого пытается взломать этот взломщик.
Сразу обговорим, что php-код, который хранится на сервере взломщику не известен. И узнать он его не может.


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

но
сервер, обнаружив, что у него другой ip и даже другой браузер, и что хеши не сходятся, мирно просит его ввести логин и пароль.
короче, такой метод не взлома не действует. Пусть user_agent и можно подобрать, но как подобрать нужный ip?
Я, если честно, не знаю. И мне кажется, что это не возможно, кроме нескольких редких исключений.

Кроме того, взломщик же не знает, что ему нужно отослать одновременно правильный user_agent и правильный ip? 
Он же не знает исходный код.


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


Но даже если есть даже шифрование, то дыры все равно остаются. 

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


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

каждый использует то что ему роднее и привычные, разницы так таковой нету!



хотя бы для того чтобы:
1. БД не продолжала искать по таблице, после того как нашла уже одну запись
2. при безграмотном кодинге бывает что на один и тот же логин принадлежит N пользователям, в этом случае его конструкция не пройдет




      
два запроса!!!


yngwie19 если тебе не важна красота формы авторизации то можешь использовать вот это

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

Вообще, я бы начинал не с авторизации.
Ведь дыра в работе с SQL к собственно авторизации не относится. 
Сначала надо осваивать элементарные вещи, "кирпичики", из которых строится веб-приложение. Работа с базой, куками. Строкамии, почтой.
Авторизация - это уже здание, которое строится из этих кирпичиков. Если их не знать, ксли они будут пустые внутри - здание развалится. Даже если на форуме покажут чертежи супер-проекта.