лучший способ обеспечить сеансы (консалтинг) - PullRequest
1 голос
/ 26 сентября 2011

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

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

Первый В: Что безопаснее, сеансы php или куки?Из моего понимания файлов cookie вы можете ограничить их только http и SSL.Не знаю, можете ли вы сделать то же самое с сессиями php.Кажется также, что php сессии - это просто быстрые куки.Печенье кажется более гибким и столь же надежным.К вашему сведению, я использую Cookies только с http и SSL.Есть ли веская причина для использования php-сессий в МОЕМ случае?

Второй Q: Мои сеансы / логин работают так: * Пароли соленые и хэшированные * Сеансы длиной в 32 произвольных символа * Сеансы проверяются при входе пользователяправильный pw и привязан к IP-адресу пользователя * Когда пользователь входит в систему, идентификатор сеанса и пароль пользователя сохраняются в 2 отдельных файлах cookie

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

Цените это, если на мои два вопроса можно ответить.Приветствуются дополнительные рекомендации по безопасности: D

Примечание. Сеансы привязаны к IP, поскольку это значительно повышает безопасность.Я предпочитаю, чтобы мои пользователи чувствовали себя немного неудобно из-за необходимости вводить свой pw при изменении их IP-адреса, когда в нашей базе данных есть номера SSN и водительские права.Только 3-5 пользователей будут иметь доступ к системе тоже.

Ответы [ 4 ]

3 голосов
/ 26 сентября 2011
  • Не не никогда не сохраняйте пароль пользователя в cookie, без представления.
  • Регулярно создавайте идентификатор сеанса
  • Используйте сильные хэши (нет MD5), как SHA512 (рассмотрим также растяжение хеш)
  • Чувствительные данные должны находиться в хранилище сеансов на стороне сервера:
    • Файлы cookie отправляются по каждому запросу кДомены куки, следовательно, увеличиваются шансы на перехват.Данные сеанса на стороне сервера выводятся только при необходимости.
  • Передача привязанного к сеансу идентификатора каждому конфиденциальному запросу в качестве токена аутентификации, чтобы избежать CSRF
  • Не связывать сеанс напрямую с IP.Два человека, использующие одну и ту же точку доступа или частного интернет-провайдера, имеют одинаковые IP-адреса, и сеансы могут быть перепутаны.
  • SSL - это , а не волшебство .Не передавайте это слишком много.
0 голосов
/ 26 сентября 2011

Является ли пароль в куки соленым и хэшированным? Осторожно - нет хорошего ответа на этот вопрос!

Связывание сеансов с IP-адресами действительно мало помогает - IP-адреса дешевы, легко подделываются и т. Д. Я бы использовал SSL, файлы cookie / сеансы, возможно, даже одноразовые файлы cookie, которые используются и сбрасываются при каждом просмотре страницы.

0 голосов
/ 26 сентября 2011

Сеансы хранятся на сервере, либо в базе данных, в файловой системе, в кэше памяти и т. Д. Пользователь привязан к сеансу по идентификатору сеанса, который хранится на клиенте либо в файле cookie, либо в URL-адресе. Ни один из них не является «очень-очень» безопасным, поскольку перехват сеанса возможен путем кражи идентификатора сеанса. Но поскольку вы привязали идентификатор сеанса к IP, вы сделали достаточно.

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

Помогает, если вы восстанавливаете идентификатор сеанса с помощью session_regenerate_id(), прежде чем предпринимать какие-либо важные действия, которые могут поставить под угрозу систему. Также обратите внимание на атаки XSS и CSRF и механизмы их предотвращения, например на токены форм.

0 голосов
/ 26 сентября 2011
  1. Сеансы хранятся на сервере, куки хранятся на клиенте (в браузере).Данные сеанса, принадлежащие пользователю, идентифицируются с помощью файла cookie (идентификатор сеанса).

Я бы сказал, что сеансы безопаснее (вы также можете применить некоторое шифрование для большей безопасности).

  1. Не храните пароль пользователя в куки.Не очень хорошая практика, даже если она хеширована.Вы можете хранить зашифрованный сериализованный массив, содержащий необходимую информацию для аутентификации пользователя: ip, user agent, username, id пользователя, но не пароль.

Вы также можете заставить работать сайт (admin CP)только по SSL.Таким образом, данные не видны в виде простого текста в сети.

...