Я укушу.
Чтобы сохранить любое подобие состояния, вам необходимо идентифицировать пользователя с помощью ключа какого-либо типа. Этот ключ отправляется в браузер в виде файла cookie ИЛИ через параметры строки запроса.
Теперь проверка этого ключа может происходить внутри самого веб-сервера (сеанс) или путем проверки какого-либо другого механизма хранения, обычно записи базы данных.
Сам ключ должен быть запутан с использованием какого-либо механизма. Причина запутывания заключается в том, чтобы просто было сложнее угадать, какие значения могут иметь другие ключи, если исходный пользователь или кто-то еще решит проверить значение. Например, если ключом является ваш идентификатор пользователя (не рекомендуется), и вы используете инкрементные числа, то угадать другие пользовательские ключи тривиально. Хочу подчеркнуть, что запутывание (или даже прямое шифрование) ключа абсолютно не защищает от взломанного сеанса. Все, что он делает, это затрудняет угадывание сеансовых ключей других людей .
Тем не менее, я считаю, что ключ не должен иметь ничего общего с вашим идентификатором пользователя и вместо этого должен иметь какое-то другое почти случайное значение, например, сгенерированный GUID. Откровенно говоря, GUID с 64-битной кодировкой находится на том же уровне безопасности, что и шифрование ID пользователя + время. Просто один из них требует больше вычислительных ресурсов на вашем сервере, чем другой.
Конечно, этот ключ может меняться при каждом запросе. Браузер что-то публикует, вы генерируете новый ключ и отправляете его обратно. В случае, если браузер публикует устаревший ключ, зарегистрируйте его и отправьте обратно на экран входа. Это должно предотвратить повторные атаки .. до некоторой степени. Однако это создает другие проблемы, такие как использование кнопки «Назад» в различных браузерах. Так что, возможно, вы не захотите идти по этому пути.
При этом вы не можете зависеть от IP-адреса клиента, поскольку один и тот же пользователь может отправлять последующие запросы с использованием другого IP-адреса. Вы не можете полагаться на дактилоскопию браузера, потому что любой приличный хакерский инструмент захватит это и отправит те же значения независимо от того, что они используют.
Теперь, если вы действительно хотите сделать это правильно, вам нужно включить SSL. Иначе ты зря тратишь время. Весь разговор (с экрана входа в систему) должен быть зашифрован. Если это не так, то кто-то может просто прослушать этот файл cookie, немедленно воспроизвести его и перехватить сеанс. Дело в том, что им не нужно знать содержащиеся в них значения, чтобы использовать их. Таким образом, все хеширование и т. Д., Которое у вас есть, - просто пух, который увеличит нагрузку на ваш сервер.
Я сказал использовать SSL? ;) Это зашифрует трафик с начала диалога, и злоумышленник не сможет воспроизвести те же пакеты, что и при согласовании своего рукопожатия с сервером. Это означает, что все, что вам нужно сделать, - это убедиться, что любой идентификатор сеанса, который вы используете, не может быть угадан, чтобы один вошедший в систему пользователь не мог взять на себя сеанс другого.
Итак, подведем итог: опубликованный вами метод - пустая трата времени.
Вам гораздо лучше просто получить SSL-сертификат за 10 долларов и использовать GUID с кодировкой Base 64 в качестве идентификатора сеанса. То, как вы храните эту информацию о сеансе на вашем сервере, на самом деле не имеет значения ... за исключением ситуаций с балансировкой нагрузки В этот момент он должен быть вне процесса и поддерживаться сервером базы данных ... но это другой вопрос.