Выполнение логина сеанса cookie id невозможен, регенерируя себя повторно

Question

Чтобы противодействовать кражу файлов cookie сеанса регистрации, обнюхиванию и т. Д., Я думал об этой схеме.

я уже читал http://jaspan.com/improved_persistent_login_cookie_best_practice и то, что я хочу сделать что-то менее сложным, может быть, производительность мудрым быстрее тоже, и то, что хорошо сочетается как с запомнить функциональность и нормальный session'ed логин.

при успешной регистрации добавить session id в таблицу user(:uid) и сгенерировать идентификатор сеанса cookie, например d6c89ddba79b4f68be07bd874c5ff566, и сохранить его в браузере пользователя.

Когда пользователь посещает другую, ту же страницу, обновляет ее; другой id будет сгенерирован и current id в таблице , cookie в браузере пользователя будет обновлен новым, сделавшим старый бесполезным || инвалид.

Если наблюдатель пытается украсть файл cookie, будь то в незащищенном соединении, например, не-https-сайт, он будет бесполезен при следующем посещении или обновлении пользователя.

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

Теперь возникает одна проблема. Я думаю, что это будет возможная ситуация, когда наблюдатель крадет куки, когда пользователь аф и бездействует, тогда наблюдатель обновляет текущую страницу с помощью этого файла cookie или посещает другой. проблема в том, что теперь пользователь вышел из системы, в то время как наблюдатель полностью контролирует свою учетную запись и поэтому может изменить пароль, если это не система, в которой смена пароля подтверждается по электронной почте или вставлять текущий пароль раньше.

что это? в этом случае, как можно реализовать эту схему без дополнительной сложности?

Answer 1

Да, это хороший способ prevent session sharing:

сервер генерирует новый идентификатор сеанса, чтобы хранить в куки каждый п число запросов. Заголовок Set-Cookie будет отправлен только один раз, так что если есть два браузер вошел в ту же сессию, один из них будет использовать старый, недопустимый сеанс

---

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

Как вы говорите, вы можете заставить пользователя подтвердить свой пароль всякий раз, когда вызывается функция высокой безопасности, например, смена пароля. Вы также можете заставить систему подтвердить свой пароль для продолжения сеанса в случае обнаружения совместного доступа (т. Е. Некоторые запросы были зарегистрированы с использованием старого идентификатора сеанса).