Желательно ли хранить хешированный пароль в файле cookie?

Я хочу, чтобы у пользователя была возможность выбрать окно "помнить меня" на моем веб-сайте, поэтому им не нужно входить в систему каждый раз, когда они приходят. Итак, мне нужно сохранить уникальный идентификатор в файле cookie, чтобы идентифицировать их. Безопасно ли хешировать свой пароль с помощью sha512 и длинной соли в PHP и хранить это значение в cookie? Если печенье было украдено, будет ли их пароль подвержен риску? Очевидно, что он должен быть связан с их паролем каким-либо образом, иначе, если значение cookie было угано или украдено, пользователь не сможет остановить другого пользователя.

Кроме того, желательно ли использовать GUID вообще как уникальный идентификатор?

Спасибо, Бен

Ответ 1

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

Ответ 2

Здесь - отличная статья по этой теме. Многие ответы на ваш вопрос затрагивают описанные в нем методы.

Ответ 3

Там низкий риск с хорошим алгоритмом и большой солью, но зачем брать любой ненужный риск?

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

Ответ 4

Не помешало бы иметь какой-то "пароль" в файле cookie вместе с идентификатором пользователя (чтобы пользователи не меняли uid на другого пользователя), просто не делайте "пароль" одинаковым как фактический пароль пользователя.

И только потому, что это хэш не обязательно означает одностороннее (ну, по определению, но есть утилиты для генерации открытых текстовых текстов MD5, и я бы догадался, что это только вопрос времени, прежде чем это произойдет с другими), Я хотел бы получить какой-то дополнительный пароль.

Ответ 5

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

Учитывая следующие предположения:

Ваша база данных защищена (например, ваше приложение может получить к ней доступ, но ваш пользователь не может напрямую это сделать, а также полагая, что приложение было проверено на внедрение SQL)
Ваши соли сильны; то есть достаточно высокой энтропии, что попытка взлома соленого пароля недопустима, даже если пароль известен

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

В то время как это защищает от повторного воспроизведения, это также означает, что если кому-то удастся украсть файл cookie в нужное время, и ему также удастся использовать его до того, как оригинальный, законный пользователь сделает, злоумышленник теперь контролирует сеанс, Можно ограничить сеанс IP-адресом для уменьшения этого риска (несколько: если и пользователь, и злоумышленник находятся за одним и тем же NAT, что является наиболее вероятным сценарием в любой домашней или малой и среднесрочной бизнес-сети), то этот момент довольно спорный вопрос, так как IP-адрес, казалось бы, то же самое в любом случае. Также полезным может быть ограничение для текущего пользовательского агента (хотя это может неожиданно ломаться, если пользователь обновляет свой браузер, а сеанс не истекает при закрытии браузера) или найти какой-либо метод, с помощью которого можно определить компьютер, на котором находится пользователь достаточно хорошо, что есть разумная уверенность в том, что пользователь не переместил файл cookie из одной системы в другую. Если вы не используете какой-либо бинарный плагин (Flash или Silver/Moonlight), я не уверен, что последнее возможно.

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

Трудно защитить приложения и, тем не менее, сохранить простоту использования. Если все сделано осторожно, безопасность может быть реализована таким образом, что она минимально навязчива и все же эффективна - ну, в большинстве случаев для приложений, ориентированных на Интернет.