логин юзера на сайт (общий вопрос по безопасности)

← →
antonn © (2007-05-23 00:25) [0]

Сижу, значит, думаю. Как наиболее качественно и при наименьших ресурсах сервера делать вход юзера на сайт? До сих пор делал так - при входе в куки пишу логин и md5 пароля. При обновлении страницы из куков достаю логин и пароль, обрабатываю от всяких нехороших символов, в $GLOBALS[] пишу значение, которое значит, что страница как для пользователя (ну и ниже по коду ее проверяю). Чем плох такой подход и как можно сделать лучше?

← →
G_M_S © (2007-05-23 09:58) [1]

Не понял, зачем логин с паролем писать в куки? Выводишь на странице логина форму, получаешь от юзера логин/пароль, проверяешь как там тебе удобно, и устанавливаешь некую переменную в сесии

$_SESSION["is_logged"] = 1

Когда юзер разлогинивается - делаешь unset($_SESSION["is_logged"])

На странице пишешь, где должны быть различия для авторизованных и неавторизованных юзеров такое:

<? if(isset($_SESSION["is_logged"])): ?>

//тут для залогиненных
//все, что угодно, включая PHP-скрипты

<? else: ?>

//Тут для прочих

Что касается хранения - можно сохранять переменные $_SESSION["login"] и пр., можно даже ID-сессии хранить на сервере, коли сильно надо
<? endif ?>

← →
Pazitron_Brain © (2007-05-23 10:27) [2]

http авторизация :)

← →
homm © (2007-05-23 10:37) [3]

> Не понял, зачем логин с паролем писать в куки? Выводишь
> на странице логина форму, получаешь от юзера логин/пароль,
> проверяешь как там тебе удобно, и устанавливаешь некую
> переменную в сесии
> $_SESSION["is_logged"] = 1
> Когда юзер разлогинивается - делаешь unset($_SESSION["is_logged"])

До чего люди наивные :) Идентификатор сессии то проще перехватить, чем хэш пароля.

← →
antonn (work) (2007-05-23 10:45) [4]

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

попытался распотрошить пхпнюку - но, блин, там закопаться можно...

← →
homm © (2007-05-23 11:06) [5]

> я ваще так понял, что сессия - это те же куки,

Не совсем. Сами данные храняться на сервере, в контейнерах (по умолчанию фалы, но можно передлать в базу, например), а вот идентификатор контейнера передаеться в куках. А если куки не подерживаються браузером, то идентификатор прилепляеться к каждой ссылке, к каждой форме, в общем везде, где может произойти переход на другую страницу.

← →
McSimm_ © (2007-05-23 12:52) [6]

> Идентификатор сессии то проще перехватить, чем хэш пароля.

Чем легче ?

← →
homm © (2007-05-23 13:28) [7]

> > Идентификатор сессии то проще перехватить, чем хэш пароля.
> Чем легче ?

Так и знал что ктонить придереться, ок не легче. Не сложнее, как минимум. Хотя опять-же он может в каждой ссылке писаться, тогдк легче.

← →
G_M_S © (2007-05-23 15:17) [8]

> До чего люди наивные :) Идентификатор сессии то проще перехватить,
> чем хэш пароля.

Вперед - перехватывай идентификатор сессии... Посмотрим, кто круче: ты или разработчики РНР.

← →
McSimm_ © (2007-05-23 15:19) [9]

Разработчики PHP тут совершенно не при чем.

← →
homm © (2007-05-23 15:23) [10]

> Посмотрим, кто круче: ты или разработчики РНР.

Какая разница. Все равно Бэтмен круче :)))

← →
Gero © (2007-05-23 16:48) [11]

> [10] homm © (23.05.07 15:23)

По сравнению со слоном бэтмен отдыхает )

← →
Real © (2007-05-24 13:14) [12]

Я обычно делаю авторизацию немного по другому: в БД держу таблицу sessions в которую пишу md5-хэш (генерируемый на основе нескольких значений, например time+ip) после проверки авторизации (если логин и пароль имеется в бд). Копия хэша - засылается юзеру в куки. Заголовком каждого файла, является выражение типа require("auth.php"); в котором проверяется хэш из куки на совпадение с каким-либо куком из таблицы sessions. Если запрос вернул 0 записей - значит авторизация неверная. Если было совпадение, то из таблицы sessions - берутся поля идентифицирующие юзера (например его ID или личные настройки. Эти данные записываются при авторизации, то есть тогда же, когда генерится хэш и заводится запись в таблицу sessions). При необходимости можно проверять и дату создания записи, если требуется ограничить срок жизни авторизации.

Взято из какой-то статьи по пхп-авторизации, автор вроде как Д.Котеров, а ему можно доверять в таких вопросах (имхо :)

Думаю яндекс, наверняка ответит большим кол-вом алгоритмов, чем форумчане в прочем :)

← →
homm © (2007-05-24 13:18) [13]

> Копия хэша - засылается юзеру в куки.

А если у езера куки отколючены, то он сосет.

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

> А если у езера куки отколючены, то он сосет.

Можно не в куки писать, а в сессию. Куки использую потому, что многие юзера хотят функцию "запомнить меня", то бишь не авторизироваться постоянно.

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

А как переписать? Перекомпилять что ли php, а потом хостеру сказать "возьмите мою новую версию пхп" ? :))))

> А как переписать? Перекомпилять что ли php, а потом хостеру
> сказать "возьмите мою новую версию пхп" ? :))))

http://www.yandex.ru/yandsearch?rpt=rad&text=session_set_save_handler

угу, а чем лучше такой вариант? :)

> угу, а чем лучше такой вариант? :)

Тем что тебе не нужно переустанавливать php у хостера, тем более самому что-то переписывать :-/

> Тем что тебе не нужно переустанавливать php у хостера, тем
> более самому что-то переписывать :-/

Издеваемся? Чем это лучше - [12] ?

> Издеваемся?

Ни чуть.

> Чем это лучше - [12] ?

аботает, даже если куки отключены.

логин юзера на сайт (общий вопрос по безопасности) Найти похожие ветки