Я использую эту структуру давно, но в последнее время начал сомневаться в ее безопасности. Проверьте плз код и укажите на недочеты. А то на душе не спокойно =)))

Этот скрипт инклюдится в основной, как проверка авторизации и ее выполнения.

Ну вроде как sql-инъекция на лицо. $_POST['login'] вроде нигде не проверяется никак и не очищается.Зловредный хацкер может это использовать

Тоесть мне нужно добавить проверку на источник $_POST['admin_login'] ?

FlameTH, sql injection премо напрашивается  

да и лучше не isset($var) a юзать !empty.

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

Ясно. Первые два шага, которые нужно выполнить это:
1) Проверить поля и саму сессию на пустое значение.
2) Экранировать спец.символы.

Это уже неплохо обезопасит. Еще что посоветуете?

не просто на пустое! А например от 3 до 15 символов + только буквы и цифры например. Это еще нужно, чтобы адекватно ответить пользователю если он случайно вписал недопустимые символы. (предупреждение о конкретной ошибке, а не просто слово "ошибка", которая почти не несет в себе информации для юзера).

респект ))

Да и ещё лучше не писать не "Неверный пароль!" и "Неверный логин!", а "Неверный логин или пароль"

А зачем делать какие-то символы недопустимыми? 
Можно сделать, чтобы все введенные значения обратывались функцией htmlspecialchars() и опасные символы, такие как "<", ">", кавычки превращались в хтмл-сущности - &lt; &gt 
после такого преобразования все введенные данные в хтмл будут выглядеть совершенно обычно, однако никакого вреда не принесут.



Здесь функция trim() убирает лишние символы пробела в начале и конце пользовательского комментария,
параметр функции ENT_QUOTES - означает, что кавычки также должны заменяться на хтмл-сущности,
а последний параметр "cp1251" - кодировка, в которой будет представлена строка.

А пароли надо шифровать md5()

Это сообщение отредактировал(а) flashaa - 14.7.2007, 13:58

Спасибо конечно, но насчет md5() хешей я другого мнения.

Я к тому, что в пароли тоже можно записать кавычки и какой-нибудь код.
Поэтому что-то делать с паролями обязательно а запрещать спецсимволы в паролях как-то не принято.
Да и хтмлспециалчарс преобразовывать тоже как-то не к месту. Что ещё остается кроме шифрования? я лично не знаю.

Отредактировано: не заметил, что у вас шифрование имеется. Вопрос снимается.


Это сообщение отредактировал(а) flashaa - 14.7.2007, 16:08

еще вариант передачи пароля по небезопасной сети ...
алгоритм такой :
1)сервер генерирует соль $salt, вписывает ее в hidden поле формы 1
2)на форме 1 также присутвует поле логин и submit
3)на форме2 есть поле пароль.
4)юзер вводит пасс, жмет субмит, его действия перехватывает javaScript, что вычислят md5($salt.$password) и вписывает его в скрытие поле формы1
5)идет остсылка $salt, $login, $md5hash
6)сервер делает SELECT из бд по логину, находит пароль.
7)делает md5($salt.$password_from_db).
8)если дайджесты (сгенерированный сервером и посланый юзером) совпали - значит авторизация ОК, иначе бэд.

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

ИМХО нельзя допускать в нике все символы. Но тут на вкус и цвет.

хэшировать лучше так: