Системы входа в систему: зачем нужны сессии? - PullRequest
4 голосов
/ 30 июля 2010

Я создавал систему входа в систему с PHP и задавался вопросом: зачем нужны сессии?

Если я сохраняю cookie с использованием идентификатора пользователя и идентификатора сеанса, разве это не создает точно такой же угрозы безопасности для хранения cookie с использованием идентификатора пользователя и хэша пароля (учитывая, что хэш пароля достаточно надежен)? Да, кто-то может украсть куки, но разве не так же, если они украдут сессионный куки?

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

Ответы [ 6 ]

3 голосов
/ 30 июля 2010

Одним из преимуществ сеанса является то, что вы можете создавать новый каждый раз, когда кто-то входит в систему, и даже периодически во время посещения пользователя. Если вы только что использовали userid и некоторый хэш пароля, то, как только кто-то украл ваши куки, они смогут войти в систему как вы на неопределенный срок. Сессии истекают.

1 голос
/ 30 июля 2010

Вы описываете конструкцию, в которой учетные данные пользователя проверяются при каждом запросе страницы, а форма входа используется только для хранения этих учетных данных в браузере.Я вижу несколько проблем с таким необычным подходом:

  • Вы передаете конфиденциальную информацию при каждом HTTP-запросе.
  • Для проверки учетных данных, которые вы, возможно, должны выполнитьзапрос к базе данных, и вы делаете это снова и снова и снова.
  • Вы должны проверить учетные данные, просто чтобы узнать, от кого поступил запрос.
  • Одновременные соединения с одинаковыми учетными данными будут совместно использовать данные [см. Приложение] .

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

Как бы то ни было, сессии и куки - это совершенно разные инструменты.Файлы cookie - это хранилище на стороне клиента, а сеансы - на стороне сервера.Они связаны друг с другом только потому, что наиболее типичная реализация сеанса использует файлы cookie для хранения идентификатора сеанса (поскольку HTTP является протоколом без сохранения состояния, такие приемы нужны для отслеживания того, от кого поступил запрос).Преимущество серверного хранилища в том, что вы имеете полный контроль над ним:

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

Приложение

В классической системе сеансов, где вы назначаете случайный идентификатор при запуске сеанса, зарегистрированный пользователь может иметь множество одновременных экземпляров сеанса на разных компьютерах (или даже на одном компьютере, например,один в Firefox и еще три в окнах режима инкогнито Chrome).Если вы идентифицируете посетителя только по его имени пользователя, у пользователя будет только один сеанс: если он пойдет домой на обед, он найдет сеанс, который он оставил на работе, если он поделится своим паролем с другом, он увидит, что его другделает.Это можно считать ошибкой или особенностью, и, конечно, есть много хитростей, чтобы предотвратить это.Просто примите это во внимание.

1 голос
/ 30 июля 2010

Вместо того, чтобы создавать хеш, почему бы не зашифровать идентификатор сеанса, чтобы вы могли расшифровать его и посмотреть, не истек ли он.

Если у вас также есть привязка к IP-адресу, вы можете сделать этоболее безопасный.

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

Как только решение будет иметь приложение javascript, которое фактически получит всю информацию дляПользователь, таким образом, имя пользователя / пароль хранится в JavaScript.Затем для каждого запроса страницы или взаимодействия передайте либо имя пользователя / пароль, либо токен, который был результатом некоторой первоначальной аутентификации, который также шифруется, как указано выше.

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

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

0 голосов
/ 30 июля 2010

Если я сохраняю cookie с использованием идентификатора пользователя и идентификатора сеанса, разве он не создает точно такой же угрозы безопасности для хранения cookie с использованием идентификатора пользователя и хэша пароля (учитывая, что хэш пароля достаточно силен)? Да, кто-то может потенциально украсть куки, но разве это не то же самое, если они украдут сессионный куки?

Да, это потенциально аналогичный риск. Кража куки может быть признана не такой серьезной по нескольким причинам:

  • Сеансовые куки имеют более короткий срок жизни.
  • Пользователи часто перезаписывают имена пользователей / пароли между сайтами, это может раскрыть их больше, если их учетные данные будут перехвачены.
  • Сессия может фактически не позволять пользователю делать то же самое, что имя пользователя / пароль; например, сайт может потребовать от пользователя повторно ввести свои учетные данные в какой-то момент.
  • Сайт может ограничить срок действия сеанса одним конкретным IP.

Но да, кража cookie сеанса может в некоторых случаях быть такой же серьезной, как кража имени пользователя / пароля. Чтобы обеспечить надежную защиту от украденных учетных данных, вы должны зашифровать (https) весь трафик между пользователями и веб-сервером (даже до их аутентификации, в противном случае активный злоумышленник может изменить action отправки формы, когда пользователь вводит учетные данные чтобы их нельзя было публиковать через защищенный канал).

0 голосов
/ 30 июля 2010

Поскольку это более безопасный период.

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

0 голосов
/ 30 июля 2010

Cookies вы можете установить, чтобы истек немедленно или через год, если вы хотели.Сессии истекают сразу после закрытия браузера.Они обычно более безопасны из-за этого.В данном конкретном случае нет разницы, которая имеет значение, за исключением срока действия и того факта, что один хранится «физически» на клиентском компьютере, а другой хранится в памяти.

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