Хорошо, помечу вопрос решенным ;)

Если такую куку украдут - считай вход открыт 

Без базы та себе сделаешь кучу проблем, но если уже ты их желаешь, то храни так:

А параметр $login_time таскай в браузерной строке. Так ты легко сможешь проверить, не вышло ли время сессии и обновлять сможешь (через ж. конечно, но работать будет) Такую куку можно и потерять, злоумышленник сможет воспользоваться ей максимум на время сессии.

A md5($pass) ты будешь обязан сделать, так как в открытом виде его после логина уже нигде не возмёшь (Ты же не собираешься пароль на сервере открытым текстом хранить??)

Но по нормальному - конечно БД. Чистить её не надо, только обновлять сессию. (Ну или убивать запись, если юзер удалён). А запрос в in_memory table будет даже быстрее, чем работа с файлами полюбому. Да и потом, ты же за логином/пассом всё равно в БД бегаешь. А тут надо будет только за ИД сессии.

Добавлено @ 01:38 

Не совсем так. Куку конечно украсть сложно, но всё таки можно. Скрипты, ссылки, флэши. Например на форуме у нас Гирдер регулярно находит такие новые дыры и закрывает их. Если подумать, что было на форуме год назад, то удивишься, как не поворовали наши аккаунты уже давно ))

Я считаю так:

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

Куки нужны только для распознавания юзера, далее все поставлено на сессиях. А вот сессии уже можно хранить в БД (убедили все же   ).  В Бд могут быть те же md5($login.' '.$pass). и время валидности сессии.

Как вам такой алгоритм?

Это ты потом докажи 100 человек, у которых скриптом с твоего сайта куки слизали и приватную переписку всех со всеми опубликовали 


Это хрени: md5($login.' '.$pass) нечего делать у юзера на компе в куках. Это во первых. Во вторых pass в открытом виде не должен существовать вообще нигде, кроме головы пользователя.

Куки нужны для распознавания сессии, а всё остальное хранится уже в ней. Зачем хранить у юзер что либо, кроме идентификатора сессии?

ПС:
ИД сессии идеале обновляется постоянно. При этом несколько вариантов учитываются как валидные, и старые потихоньку отмирают.

Ясное дело! Поэтому я храню это в БД у себя.

То есть в куках хранить SID будет наиболее приемлемым вариантом?

Можно спросить, зачем?
Если юзер поменяет ник, ему надо будет новый пасс задавать?

По-моему мы пришли к тупику. Если куки такие ненадежные - их тогда совсем не использовать? Собственно можно ответить "Да" но замены cookie еще нет, Поэтому, если хотим помнить о посетителях  - используем cookie, в таком виде, как я указывал ранее.

Насчет хранения сессий (БД/файлы) это уже имхо другая тема. Вообще к БД доступ лучше,быстрее да и удалять из нее инфу легче. Так что наверное буду использовать БД.

Почему куки ненадёжные? Храни СИД в них, время жизни которого на сервере контролируется. Ну и логин, чтобы перебором никто не попытался пройти.
Больше ничего не надо. (Так и тут на форуме сделано).

sergejzr, Тогда время жизни сессии нужно большим устанавливать, если я тебя правильно понял.

Если мы хотим Помнить  о юзере как минимум неделю. А в куке хранится SID. По этому SID мы обращаемся в БД и смотрим не просрочена ли сессия, если просрочена - удаляем сессию, и просим зарегиться пользователя?

Да. 

С несколькоми сессиями - это не обязательно делать тут овчинка выделки нестоит. Но неплохо было бы "освежать" их. В идеале - при каждом вызове страницы давать новый СИД. Тогда даже если ктото украдёт его, то юзер "вылетит" со страницы, и большой шанс, что он это заметит и тут же залогинится. Тогда старый СИД у нападавшего станет бесполезным, он же не может новый получить.

Но тут надо конечно с нагрузкой на БД сравнивать. Это же обновление записи при каждом входе. Можно например по времени генерить, каждые 5 минут.

Проблема с таким подходом только в разных браузерах, так как куки обновятся только в одном. Тут помогло бы несколько сессий. Для каждого браузера своя независимая. В принципе оверхеда практически нет. Просто логину в стблице СИДов добавляешь хэш юзер-агента. 

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

В общем, думаю использовать такой вариант:

Будет БД:
session_id – SID сессии;
session_expire – microtime последнего действия (точность до сотых);
session_start    -  время логина (microtime до сотых секунды).
user_id – ID юзера;
login – хеш логина;

Куки:
SID 
Время логина
Хеш логина юзера

Соответственно ищем запись в Бд по SID, а потом проверяем: равны ли логин и время логина.
Время действия можно задавать в конфигах, думаю мне подойдет 5 дней.


Интересно что будет с БД. Если 10 000 человек будет бродить по сайту, и у каждого будет меняться microtime последнего действия? 

Если будешь менять его раз в несколько минут, то ничего страшного не будет.


А Вы, батенька, оптимист однако 

Эврика! Тогда берем microtime из бд и проверяем, если он больше 5 минут - обновляем (к примеру...)



Еще какой!  

Еще один вопрос по теме:
Если мы начинаем сессию (чтобы узнать SID) - создается файл. Через определенное время их будет слишком много. Что делать?

Файл будет если ты через ПХП создаёшь. У тебя же БД, зачем тебе теперь он?