Я хочу, чтобы у пользователя была возможность выбрать окно "помнить меня" на моем веб-сайте, поэтому им не нужно входить в систему каждый раз, когда они приходят. Итак, мне нужно сохранить уникальный идентификатор в файле cookie, чтобы идентифицировать их. Безопасно ли хешировать свой пароль с помощью sha512 и длинной соли в PHP и хранить это значение в cookie? Если печенье было украдено, будет ли их пароль подвержен риску? Очевидно, что он должен быть связан с их паролем каким-либо образом, иначе, если значение cookie было угано или украдено, пользователь не сможет остановить другого пользователя.
Кроме того, желательно ли использовать GUID вообще как уникальный идентификатор?
Спасибо, Бен
Помните, что хэш пароля фактически совпадает с его паролем. Кто-то, кто украл хэш, будет иметь тот же доступ к учетной записи пользователя, как если бы он украл свой пароль. Поэтому рекомендуется не хранить хэш пароля пользователя в файле cookie, если только некоторая другая информация не хранится в файле cookie, который используется для аутентификации (например, двухфакторная аутентификация).
Здесь - отличная статья по этой теме. Многие ответы на ваш вопрос затрагивают описанные в нем методы.
Там низкий риск с хорошим алгоритмом и большой солью, но зачем брать любой ненужный риск?
Если вам просто нужно идентифицировать пользователя, тогда сохраните то, что может однозначно идентифицировать пользователя, например, руководство вместе с каким-либо другим сохраненным кодом подтверждения (а не их паролем, некоторой случайной длинной строкой). Я бы не использовал руководство, поскольку это не был бы безопасный метод аутентификации.
Не помешало бы иметь какой-то "пароль" в файле cookie вместе с идентификатором пользователя (чтобы пользователи не меняли uid на другого пользователя), просто не делайте "пароль" одинаковым как фактический пароль пользователя.
И только потому, что это хэш не обязательно означает одностороннее (ну, по определению, но есть утилиты для генерации открытых текстовых текстов MD5, и я бы догадался, что это только вопрос времени, прежде чем это произойдет с другими), Я хотел бы получить какой-то дополнительный пароль.
Альтернативным способом сделать это может быть использование файла cookie в качестве зашифрованного хранилища только для данных о направлении. Вам понадобится какой-то незашифрованный идентификатор, который будет служить указателем на ключ (или необходимую информацию для получения ключа) в базе данных приложения, за которым следует blob, зашифрованный ключом, полученным из идентификатора, который сам будет содержать какой-то одноразовый идентификатор, который аутентифицирует сеанс.
Учитывая следующие предположения:
Тогда то, что это обеспечило, - это метод, с помощью которого можно быть достаточно уверенным, что сеанс не может быть захвачен или украден каким-либо образом. То есть скопированный файл cookie имеет ограниченную полезность, поскольку пользователь не должен использовать cookie между его кражей и использованием злоумышленником.
В то время как это защищает от повторного воспроизведения, это также означает, что если кому-то удастся украсть файл cookie в нужное время, и ему также удастся использовать его до того, как оригинальный, законный пользователь сделает, злоумышленник теперь контролирует сеанс, Можно ограничить сеанс IP-адресом для уменьшения этого риска (несколько: если и пользователь, и злоумышленник находятся за одним и тем же NAT, что является наиболее вероятным сценарием в любой домашней или малой и среднесрочной бизнес-сети), то этот момент довольно спорный вопрос, так как IP-адрес, казалось бы, то же самое в любом случае. Также полезным может быть ограничение для текущего пользовательского агента (хотя это может неожиданно ломаться, если пользователь обновляет свой браузер, а сеанс не истекает при закрытии браузера) или найти какой-либо метод, с помощью которого можно определить компьютер, на котором находится пользователь достаточно хорошо, что есть разумная уверенность в том, что пользователь не переместил файл cookie из одной системы в другую. Если вы не используете какой-либо бинарный плагин (Flash или Silver/Moonlight), я не уверен, что последнее возможно.
Для защиты от постоянного захвата сеанса требуется, чтобы пользователь периодически повторно проверял его (например, ограничивал продолжительность сеанса сеанса или требовал что-то вроде токена/фоб/ключа) и требовал, чтобы пользователь повторно аутентифицировал его или при входе в чувствительные области приложения, такие как смена пароля и потенциально опасные действия, шаблоны или поведение, такие как удаление данных, необычные шаблоны использования, массовые действия и т.д.
Трудно защитить приложения и, тем не менее, сохранить простоту использования. Если все сделано осторожно, безопасность может быть реализована таким образом, что она минимально навязчива и все же эффективна - ну, в большинстве случаев для приложений, ориентированных на Интернет.