Как безопасно запоминать пользователей с файлами cookie? - PullRequest
4 голосов
/ 15 мая 2011

Итак, допустим, у меня есть веб-сайт базы пользователей, и когда пользователь входит в систему, я помещаю куки (или сеанс) с парой ключ-значение, помня, кто пользователь. Но это просто привлечь мое внимание, какую информацию я должен использовать, чтобы запомнить пользователя, чтобы он был в безопасности. Я не могу использовать username = username или user_id = user_id (потому что мой user_id будет 1), потому что тогда люди могут просто угадать, что это за значения cookie, и войти в систему под этим пользователем. Так какую пару ключ / значение я должен использовать, чтобы иметь возможность идентифицировать пользователей и при этом безопасно подключать их информацию к базе данных? Спасибо.

Ответы [ 4 ]

1 голос
/ 15 мая 2011

Я определенно не эксперт в области безопасности, но я недавно внедрил инструмент управления пользователями и сделал следующее.

  • Не используйте шифрование, оно медленное и большую часть времени для простой реализации - просто трата времени.

Вот что вам нужно хранить насервер - для аутентификации каждого запроса.

  • UserId (очевидный)
  • CookieHash (сделан из userId, некоторого секретного секретного ключа и случайно сгенерированного номера шифрования)
  • LastLogin
  • SessionRenewed (полезно, когда нужно отменить чей-то сеанс, например, обновлять cookieHash каждые 10 минут, в противном случае выйти из системы)
  • LastIP

Что я хранюв cookie следуют

  • UserId
  • CookieHash

Как использовать эту базовую защиту

Просто, когда пользователь входит в систему, вы проверяете имя пользователя/ пароль и т. д. (как обычно) Если все в порядке, войдите в систему пользователя и сгенерируйте новый cookiehash и заполните значения, указанные выше.

Каждый запрос проверяет UserId на его хеш.Если кто-то дал UserId = 4, но хеш-код не совпадает, тогда автоматически отбросьте сеанс и перенаправьте пользователя на экран входа.Возможный журнал полезен, чтобы увидеть, как часто люди пытаются поиграть с вашей тяжелой работой.

Надеюсь, это поможет.

1 голос
/ 15 мая 2011

Если вы не предпочитаете шифрование по какой-либо причине, то более простым решением может быть использование GUID для идентификации пользователя. Таким образом, хакеру потребуется запустить атаку типа «отказ в обслуживании» на ваше приложение, чтобы иметь возможность проходить даже через очень небольшую часть GUID.

Если вы хотите сделать это правильно, то вам стоит взглянуть и на http://jaspan.com/improved_persistent_login_cookie_best_practice.

1 голос
/ 15 мая 2011

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

https://www.owasp.org/index.php/Session_hijacking_attack

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

https://www.owasp.org/index.php/Session_Management

0 голосов
/ 15 мая 2011

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

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

Хотя я не думаю, что это основные препятствия, они могут быть для вас, и вам придется оценить влияние на ваш сайт для себя.

...