это можно сделать всегда независимо от кол-ва проверок, если есть скарденная сессия.
Главное не писать в куки пароль.

А вообще, если честно, сабж вообще не понял

Сто процентно безопасно. Но я бы при логинке если авторизация прошла успешно, заносить md5 user_agent'a + соль в сессию, а уж потом сравнивать значения - тогда точно никто сессию не угонит, да и авторизация не будет слетать при смене ip.

Попробуем разобраться

Для начала, определим участников: Итак, первый протокол: Несложно заметить, что данные проверяются только в первый раз, после чего безопасность протокола основана только на
идентификаторе сессии (sess_id).

Насколько надёжен такой подход? По умолчанию, размер sess_id - 128 бит, а значит, чтобы найти его методом перебора, понадобится около 2^128 взаимодействий с удалённой системой. Это не кажется очень реалистичным.

С другой стороны, если sess_id станет известен Мэллори, он сможет отправлять и получать сообщения от имени Алисы.

Перейдём ко второму протоколу: Теперь, казалось бы, надёжность должна значительно повыситься, и даже при компрометации sess_id система останется безопасной.

Но рассмотрим то, как осуществляется проверка.
При каждом запросе Алиса будет отсылать sess_id, которому соответствует некий набор данных на сервере - session. Чтобы проверить, действительно ли это её сессия, необходимо вычислить хэш и сравнить его с сохранённым.

Для этого, в свою очередь, нужно получить ту самую соль, которая была использована при авторизации. Проблема в том, что единственное, что связывает "ту" Алису и "эту" и говорит, какую соль использовать - это sess_id. Замкнутый круг.

Зачем же здесь тогда функция md5 и соль, если они не обеспечивают дополнительную проверку?

Очевидно, что хэширующая функция не даёт узнать начальное значение, а соль мешает эффективно использовать атаку по словарю, но... если у Мэллори есть права на чтение и ему удалось прочитать файл сессии, то атаковать хэш ему уже не понадобится.

astrologer При нормальном разграничении прав - Мэллори не сможет прочитать файл сессии. Если же у Мэллори будут права на чтение того же пользователя, что и пользователь данного хостинга - то прочитать можно гораздо более интересные файлы, а это уже полная компрометация сервера

Хэш от юзерагента+соль делает бессмысленным XSS атаки, что в большинстве случаев и нужно

О_о есть еще много способов как использовать xss.... К примену в активках реально устроить фрейм на связку, csrf... Ajax/json-hijacking, XML-injection иногда способов куча

ChaaK Угу, все это конечно очень относится к теме заданной ТСом - сессия и способы авторизации? Может вы еще перечислите вообще все виды атак? И это тоже будет очень в тему?

Возможно, конечно, не правильно сформулировал - пусть будет так - "бессмысленными XSS за тем, чтобы получить сессию"

Мне показалось, я подробно объяснил. Разумеется, саму сессию получить с помощью XSS нельзя - она храниться на сервере, можно получить её идентификатор, который может быть в куках или в адресе.

Как только он получен - хэш и соль становятся бессмысленными, имеет значение только строка user_agent, которую совсем несложно узнать, если это была XSS.

Даже если Мэллори не знает, какой браузер использует Алиса (что уже маловероятно), он будет просто по очереди использовать разные заголовки, в порядке убывания распространённости браузера. С учётом статистики понадобится всего около 5 попыток

делать привязку к ип/индентификатор сесии, правдо при смене ип(например пров лаганул а ип динамический) надо заново логинется(кстати именно так на ачате), конечно сушествует вероятность того что угнавшему ид сесии удастся зайти с этого ипа(например одинаковый пров с nat) но это вероятность мала,имхо.