авторв гугле в сессии хранится ключ ip адреса и юзерагента скорее всего и проверяется
в сессии может храниться хоть имя отца и матери - ключевое слово в сессии !
сессионная кука - ключ к информации!

- при каждом запросе ид сессии будет новым и, пользователь, который вылетел из сессии может предположить, что его кука у другого...
механизм блокировки врага - смена пароля (как пример, или GUID, или ещё что), который при каждом запросе запрашиваем у БД и сверяем с сессионным значением!
IP хранить\сравнивать ИМХО глупо - есть люди с динамик IP - что делать им? юзерагент - может и да - минимум будет!
вообще тема просторна и интересна - серебрянной пули естественно нету - но твой вариант слишком простяцкий - уж извини ;)

P.S. подумалось - а роли в твоей прожке не булут использоваться?

авторМожно завязывать не на конкретный айпи, а на сеть класса Д скажем.
да-да! proxy, wifi and etc! обсуждалось 1к раз! узнать реальный IP клиента дело не всегда простое и, не всегда клиент с др. IP не тот же клиент, что был раньше...
проблемы 2-е
1 - узнать , что твоя кука стала достоянием др. человека!
2 - кикнуть врага из своей авторизации!

авторИМХО первое обнаруживается только в виде следов деятельности. Вряд ли раньше можно заметить, если постоянно не мониторить сессии.

http://php.net/manual/en/function.session-regenerate-id.php
автор4.3.3 Since then, if session cookies are enabled, use of session_regenerate_id() will also submit a new session cookie with the new session id.
то есть, если мы авторизованы и сидим в своей авторизованой сессии и, со следующим запросом вылетаем из авторизации - то, вероятно кто-то другой уже перегенирировал ид нашей сессии и, мы со своим ид уже устарели. Каковы наши действия?
авторВторое достаточно просто решается когда куки хранятся в базе - убить все активные авторизации пользователя.
чувствую руку администратора ;) я сидел в 24:00 в авторизованной сессии и, вылетел!!! пишу письмо админу?! (он же не спит ;) - тот открывает БД и "убивает все активные авторизации пользователя" (С) (то есть меня ;)
м.б. мне легче побырому залезть в акк и поменять пароль?! ;)

Усложнить жизнь чужому от воровства конечно же как и говорили (мну в том числе)
1 юзерагент - может и да - минимум будет!
2 http (s)
3 что нибудь ещё

P.S. кстати, все эти мероприятия относятся к авторизации пользователя при помощи сессионной куки!

авторЕсли лень авторизоваться и нажать кнопку "убить сессии" - то да.
я, конечно, не много где авторизуюсь, но! в тех местах (даже в инет-банках! ;) кнопка "убить сессии" - как-то отсутствовала (only exit)!
авторСессии от этого сами не убиваются. Обсуждалось. В поиск.
а сессия тут и нипричём. запрос клиент-сервер - сравнивается хэш имени-пароля (например) из сессии с БД - как бэ всё.
авторВ общем случае добропорядочный пользователь может быть вполне легитимно залогинен с нескольких браузеров (или девайсов). Сессия будет одна или две-три-пять? ;-)
и что? сколько браузеров - столько сессий - где подвох? каждая сессия будет работать вполне себе автаномно!

откуда вообще столько негатива? или как всегда - ни о чём?

угу...

какого такого?! Кражи сессионной куки?

ты такая милая! ;)
твой вэб-сервер навсегда запрещает твоим клиентам лезть в порносайты, ловить вирусы на свой комп, устанавливать вредоносное ПО и тд. до и после его посещения...
От души завидую!!!

авторМожно завязывать не на конкретный айпи, а на сеть класса Д скажем.
Юзер агент даст дополнительный бонус в безопасности, особенно если в случае его не совпадения сессию убивать.
мы можем зайти в инет-кафе - надеюсь это будет "сеть класса Д"? ;)
прикольный админ перехватывает нашу куку и со своего компа рулит на нами авторизованый ресурс, "Юзерагент", полагаю, у него не будет сильно отличаться от нашего!
потом, при случае, нам расскажут о следах его деятельности, возможно! ;)

авторЧерез SSL ловит?
12832075 + ты заметил на этом ресурсе SSL?! а таких ресурсов (с авторизацией без SSL) по нету пруд-пруди ;)
авторТрояны тырять куки в кафе?
с "весёлым админом" и трояны не понадобятся! + запросто! кто же там особенно будет следить за секьюрностью ПО?!

Мну не понятно, что именно, вы хотите мне доказать?
Что предложенный мною вариант, не соответствует вашей логике, или логике в принципе?

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

автортрололо
что - аргументы закончились?! ;)

ТС
после продолжительных и оч сложных дебатов ;) мои рекомендации остались неизменны


это даст вполне себе нормальную (не оч затратную!) защиту от кражи сессионной куки авторизованного пользователя + я использую проверку браузера (но! это по вкусу, т.к. просто слегка усложняет жизнь ворам и, не даёт 100% гарантии). Проверку по ИП использовать не рекомендую, в силу причин изложенных мною ранее!!!
Так же, рекомендую задуматься о механизме кика вора (банальной сменой пароля) честно авторизованными пользователями, в случае обнаружения утечки! (этот механизм так же был описан мною ранее;)

P.S. естесственно, можно, забить на эти рекомендации, и подождать, пока мои оппоненты, собравшись с мыслями, найдут в гугле "сами незнаем что", и предложат, менее затратные и более эффективные, средства управления авторизацией\аутентификацией пользователей!!! ;)))

Успехов!!!

авторИмхо такая система легко обходится при прекращении деятельности юзера. Достаточно просто перехватить последний пакет с сайта простым снифером, и подставить по аналогии себе.
рациональное замечание, но, не факт, что эта сессия будет авторизована!
авторПо айпи какраз проверять стоит, так как сразу отпадает все кражи через троянов: хакеры получить то получат твои куки, а с ними ничего сделать не смогут.
пусть будет так! мне попрежнему думается, что это избыточно + может вызвать проблемы с нормальными пользователями!


12831694 6 июл 12, 22:11

авторОбьяснте подробнее на русском что делает
сессия, в PHP, по умолчанию, насколько я понимаю, сохраняется в ФС (в виде файла с опр именем)!
если сделать


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


даёт понять пыху, что старый сессионный файл как бэ уже и не нужен и он удаляется сразу (или почти сразу ;) после создания нового! Т.е. при наличии старой сессионной куки сервер уже не обратится к старому сессионному файлу тк его просто не существует - сессия протухла!
авторЕще интересует в кукисах id сессии само должно обновиться
ДА!
авторУбить сессию, если юзер не шевелился в течении 15 минут, без всяких разговоров и объяснений тчк
мне казалось это настолько очевидным, что как-то и не подумал говорить здесь об этом ;)
естественно!
авторНо я предлагаю совсем другой вариант авторизации без кукисов .
Просто авторизуемся с помощью сессии и на аяксе отправляем каждую минуту запрос на поддержание ссесии чтобы не вылетить с сайта.
см. скрин - там аякс запрос ;)