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

Не дать перехватчику куков авторизовать можно только привязав аккаунт к IP.

зачем тогда в этой теме все пытаются хранить в куках что то странное, а не логин/пароль в чистом виде?

хорошо, еще раз: если хеш дает доступ к аккаунту наравне с парой логин/пароль, то какая разница? Или у вас защита по принципу "захешировать/зашифровать все что возможно, а разбираться потом будем"?

речь о запоминании между сессиями, верно (по крайней мере я только об этом спрашивал) ? IP между сессиями меняется, опять же не понимаю какая польза от него здесь. К тому же на одном IP может быть несколько пользователей.

Повторяю: если в куках будет хэш пароля, этот пароль можно будет восстановить (брут, радужные таблицы). Потеря пароля страшнее потери аккаунта.

Вот именно. Поэтому толку от привязки мало. Разве что привязывать к подсети.

Не наравне. Особо важные операции обычно требуют повторного ввода пароля, как например, его смена. Опять же, сессия может и умереть, в отличие от логина/пароля.

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

речь про запоминание между сессиями.
.... вообще то .... .... короче я понял, в чем фишка айдишника предложенного B@rmaley-ем: злодей по нему так же может авторизоваться, на этом этапе разницы никакой, но вот дальше-то я ничего не продумывал, а дальше так: злодей авторизуется, id меняется и записывается ему в куки, теперь злодей может спокойно заходить на чужой аккаунт, id при этом каждый раз в куках и в базе меняется, дальше приходит настоящий владелец, зайти по id не может, т. к. у него остался старый id, вводит пароль, id опять новый и у злодея он уже устарел, если он не имеет возможности второй раз добыть новый id, то он отдыхает. Нужно только id делать не совсем случайный, а случайный из незанятых.

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

Плюсы варианта с логином в куках:
1. нет мизерной вероятности попадания взломанного пользователя на случайный аккаунт. (Вероятность настолько ничтожна, что можно не считать.)
2. хеши вместо чистых id в базе. (Тоже можно не считать, почему объяснил выше.)
3. если id не подошел, то можно поле "логин" из куков заполнить. (Хоть что-то значимое.)
4. раз сервер знает логин из куков, он может предупредить пользователя id которого не подошел, что на его аккаунт заходили с другого компа. (Вот это действительно значимый плюс.)

Минусы варианта с логином в куках:
1. логин в куках в чистом виде. (Можно не считать, т. к. в варианте без логина в куках увидеть этот логин тоже не проблема.)




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

UPD: афигеть, понаписал.

UPD2: сорри, плюсы не ставятся, для Kolyaj понятно почему, недавно добавлял, а вот почему B@rmaley-ю не хочет ставить, загадка.

Зачем контролировать случайность, когда можно сделать такой id, какой нужно? Возьмем мешанину из

md5($login . $ip. microtime() . mt_rand() /* добавить еще переменных по вкусу */)

Если только защищаться от коллизий md5...

да, я про это как раз.

Это слишком маловероятная вещь, чтобы от неё защищаться.

для меня лучше когда на 100% .

Riim,
преждевременная оптимизация это называется.