Форум PHP

Здравствуйте, подскажите

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

Вот например так.

Форма для ввода логина и пароля и отправка POSTом
В базе проверяем есть ли этот пользователь и если есть присваиваем выбранный массив переменной $_SESSION, т.е. $_SESSION['user'] =выбранный массив из базы;
Далее допуск до разделов если isset($_SESSION['user']) существует

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

чутьчуть не успели на разбор такой темы :)
http://softtime.ru/forum/read.php?id_forum=1&id_theme=67215

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

Тогда как выход это привязывать id сессии к айпишнику?

Как я то непонятка, подскажите что не так. Здесь http://www.softtime.ru/bookphp/gl8_1.php
написано, что: "При использовании сессий данные сохраняются во временных файлах на сервере."

а здесь http://www.softtime.ru/info/articlephp.php?id_article=36 что "Рассмотрим типичный процесс авторизации с использованием сессии..... 4. SID записывается либо в cookies браузера, либо передается через адресную строку браузера (если cookies отключены). "

Так где хранится id сессии?

Заранее и по факту отклика всем спасибо )))

>Как я то непонятка, подскажите что не так. Здесь http://www.softtime.ru/bookphp/gl8_1.php
>написано, что: "При использовании сессий данные сохраняются во временных файлах на сервере."

верно, "деньги" лежат дома!


>а здесь http://www.softtime.ru/info/articlephp.php?id_article=36 что "Рассмотрим типичный процесс авторизации с использованием сессии..... 4. SID записывается либо в cookies браузера, либо передается через адресную строку браузера (если cookies отключены). "

Тоже верно, "ключ от дома" у нас в кармане или в руке.

А вот еще верней, лопата уже на взмахе для таких вот метафорных товарищей

или Вы меня не поняли или я Вас..


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

- SID (это ключ), который хранится в куках или передается через ГЕТ и ПОСТ.
Вот по этому СИДу скрипт и узнает юзера.

Спасибо большое за разъяснение )))

только остался самый главный вопросик ))) - Решением безопасности - это привязывать id сессии к айпишнику?

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

Могу предложить так:
Пользователь при вводе пароля получает куку, которая сообщает серверу, что этому пользователю можно немного доверять, ведь он как-то сумел получить куку. Управляющие сайтом скрипты, при этом должны лежать в отдельной директории, защищенной средствами apache. Выходит, чтобы проникнуть в защищенную директорию(т.е. управлять содержимым) нужно не только попытаться доказать знание пароля нужного аккаунта, но и знать непосредственно логин/пароль защиты средствами apache? для входа в защищенную директорию. Со старта авторизации, т.е. с момента получения нужной куки, хорошо бы запустить механизм сессий, который будет проверять на каждой странице юзер агент и ip адрес.

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

Решение безопасности (защита от подделки сессии) есть проверка на сходимость заголовков user-agent (браузер) и ip нескольких последовательных запросов посылаемых клиентами (клиентом). Как это реализовать можно узнать тут
http://softtime.ru/forum/read.php?id_forum=1&id_theme=67215
в массиве $_SERVER хранится информация о браузере и ip (и не только конечно) посетителя соответственно нас интересуют элемент $_SERVER['HTTP_USER_AGENT'] и $_SERVER['REMOTE_ADDR'], соответственно сохранив эту информацию от первого посетителя, который открыл сессию, мы сможем блокировать попытки открыть сессию другим пользователем, если он не подделает заголовки запроса соответствующие конечно.

А какова вероятность того, что идентефикатор новой сессии будет таким же ?

Смотря какой идентификатор.

Простите, не понял, поясните.

У вас проблемы с созданием одинакового идентификатора для всех пользователей? Или я не правильно понял?

У меня проблем нет, я отвечаю на сообщение heed (19.08.2009 в 15:23)

Вероятность небольшая , но я уже видел в своём скрипте "Здравствуйте (другой пользователь)"
После этого как-то пропало желание всё делать на одной только сессии

И насчёт привязки к IP тоже попадал в ситуацию , когда перед каждой загрузкой страницы приходилось подтверждать что я не против что мой IP изменился
(скрипт не мой) , раз 12 подряд.
Не выдержал и отключил такие настройки в личной панели этого скрипта

Это что у вас при загрузке каждой новой страницы ip менялся ?

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

Несомненно)

.

Может нужно выбрать интернет-провайдера поприличнее?

я.бы не сказал что здесь неприличные сотовые провайдеры , у всех edge есть.
Выбрал сразу всех четырёх .)
Есть даже неплохие расценки. Например 120 абонентской платы за бесплатных 250Mb ежемесячно, и <2 за метр после израсходования, даже так и тянет совсем перейти на мегаfon'овый модем.
если по проводам, слышал есть 1000 в месяц безлимит , мне столько не надо ,) и около 2х тоже за метр вроде

Приличным я называю провайдера, который на установленном соединении не пытается менять IP хотя бы сутки.
Независимо от расценок и проч.

Точно не помню, но по-моему: число симбволов, которые используются в диапазоне в степени количества симбволов в строке.

33^26 = 3,0294405677241226503105909075986e+39

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

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

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

Для улучшения безопасности стоит хранить ещё уникальный хеш, который идентефицирует пользователя и сравнивать его предведущее значение (хранимое в сессие) с текущим. Например контрольную сумму от его IP адрес и юзер-агента. Хотя это не прибавит существенной безопасности, а остановит лишь делетантов (если человек смог перехватить данные с айдишником сессии, то что ему мешает подделать свой юзер-агент и айпишник?).

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