Как мне хэшировать пароли перед публикацией, а затем использовать BCRYPT?
Я делаю систему входа в систему, и при входе в систему пароль в настоящее время отправляется из JavaScript в файл PHP.
В PHP я использую следующий фрагмент кода для хеширования.
$hash = password_hash($_POST['password'], PASSWORD_BCRYPT);
Как мне хешировать пароль в JavaScript перед его отправкой с помощью POST?
Я явно не хочу влиять на безопасность BCRYPT.
Сделайте хэш пароля с MySQL, используя SHA1 или SHA2, затем сравните с SHA пароля клиента к базе данных. Используйте SSL для защиты данных, передаваемых по линии.
Хеширование паролей в веб-интерфейсе ДОЛЖНО выполняться независимо от использования https. См. Объяснение здесь: stackoverflow.com/a/21716654/43615
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 3
без HTTPS не обращайте внимания на то, чтобы делать такие вещи на стороне клиента, потому что они все равно запутают ваш код, увидев ваш алгоритм шифрования.
Я использую HTTPS, но как вы думаете, мне не следует хешировать его перед отправкой? Это безопасно?
Если алгоритм находится на клиенте, любой может его увидеть, поэтому попытки шифрования на стороне клиента бесполезны.
Поскольку вам нужно использовать секретный ключ, он каким-то образом будет храниться у клиента, а это значит, что вы ему все дали. просто используйте сообщение формы и сохраните его в своем SSL-канале, кстати, вам обязательно нужно использовать шифрование при доступе к базе данных.
Спасибо за советы!
Существует так много непонимания того, как работают хеши и шифрование. Если, конечно, вы не станете шифровать симметричным ключом. Вы бы либо использовали асимметричную технику, когда отправитель, который шифрует данные, имеет только открытый ключ и только сервер с его закрытым ключом, и посмотрите, что было зашифровано. Или, что еще проще, метод хеширования с использованием соли (или одноразового номера) означает, что злоумышленник может видеть хешированное значение, но не может воссоздать из него исходный пароль (в этом суть хеша) и не может повторно использовать тот же хеш, если сервер отправляет одноразовый номер (Google, который)
То, что делается на стороне клиента, на самом деле не контролируется вами. Я имею в виду, что даже если вы хешируете свой пароль, клиент может получить пароль перед хешированием / шифрованием.
var password = document.getElementById('login').value;
console.info(password); // It is as simple as it
//hash password...
Выше простого примера для объяснения, клиент может получить пароль, подобный этому, или кто-то другой может получить его с помощью атаки XSS. Вы должны сделать все возможное, чтобы защитить своих клиентов от XSS, но тогда вы не сможете контролировать то, что происходит на стороне клиента.
Если вы опасаетесь атаки Человек посередине (MITM), самое важное - использовать сертификат TLS с правильным алгоритмом (это зависит от версии OpenSSL вашего сервера). Короче говоря, использование HTTPS - это то, что вы должны делать, чтобы защитить своих клиентов от атаки MITM.
Итак, по мне, перед отправкой паспорта не требуется хешировать / шифровать.
Спасибо, это в точности объясняет мою озабоченность (и насколько я ошибался).
Пожалуйста! Иногда сложно понять, что клиентская сторона небезопасна. Есть правило Никогда не доверяйте вводу пользователя, потому что браузер не контролируется вами. Поэтому вам следует закрепить его как можно сильнее, но тогда нельзя быть уверенным в его безопасности.
Если хотите, можете поиграть с какой-нибудь реализацией bcrypt на стороне клиента (ищите "bcrypt js", там пример реализации).
НО, это означает, что вы должны использовать одно и то же значение соли между сервером и клиентом. Этот ответ объясняет.
Следовательно, если клиент скомпрометирован, значение соли вашего секретного сервера также будет.
НО, что ты имеешь в виду? Если вы считаете, что более безопасно отправлять и сравнивать хэш вместо того, чтобы отправлять один раз простой пароль и хешировать его на стороне сервера, вы ошибаетесь. Человек посередине украдет пароль или хеш и нарушит безопасность.
Правильный ответ был дан в комментарии: лучше использовать HTTPS для лучшей безопасности. По крайней мере, используйте дайджест-аутентификацию, если вы не можете использовать протокол HTTPS (Что такое дайджест-аутентификация?)
Хеширование на стороне клиента не делает его более безопасным. Используйте HTTPS для связи и используйте хеширование паролей + соление на стороне сервера для хранения паролей.