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

Question

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

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

Спасибо, Бен

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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