авторв гугле в сессии хранится ключ 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)!
авторСессии от этого сами не убиваются. Обсуждалось. В поиск.
а сессия тут и нипричём. запрос клиент-сервер - сравнивается хэш имени-пароля (например) из сессии с БД - как бэ всё.
авторВ общем случае добропорядочный пользователь может быть вполне легитимно залогинен с нескольких браузеров (или девайсов). Сессия будет одна или две-три-пять? ;-)
и что? сколько браузеров - столько сессий - где подвох? каждая сессия будет работать вполне себе автаномно!

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

угу...

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

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

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