Password_hash() 提交前需要预散列吗？答案

【问题标题】：Password_hash() need of pre-hashing before submit?Password_hash() 提交前需要预散列吗？
【发布时间】：2015-01-10 19:08:30
【问题描述】：

我正在使用 PHP 5.5+ password_hash() 函数在存储到数据库之前对我的密码进行哈希处理。到目前为止一切顺利。

我有点不确定是否需要对从表单发送到我的 PHP 脚本的密码进行预散列处理。

现在表单提交过程（简而言之）是这样完成的：

包含表单的 HTML 文件在表单方法 =“..”中调用控制器脚本 ->
控制器脚本接收调用并选择正确的函数 ->
函数执行和存储到数据库。

所以基本上调用是通过从提交到存储的三个文件发送的。

我认为，由于散列是在第三个也是最后一个文件中完成的，因此数据可能会被劫持并以普通视图查看。

在初次提交表单时，我是否应该担心并以某种方式使用 JavaScript 对密码进行哈希处理，或者这样做是否安全？最终站点很可能会使用 SSL 证书，但我仍然不能 100% 确定我是否安全。

【问题讨论】：

如果您在将密码发送到网络服务器之前在浏览器中对密码进行哈希处理，然后在服务器上再次进行哈希处理，您几乎肯定会削弱最终存储的密码，因为初始哈希会降低熵密码....如果您通过 SSL 发送，那么您的浏览器和网络服务器之间的安全性由 SSL 处理，因此无需在浏览器中进行散列
所有 PHP 脚本都在一个解释器实例中执行。一个非问题主要是 PHP 如何读取表单/POST 数据。如果有有一个文件附件，则创建一个临时文件（对于大多数登录表单来说不太可能）。您可能会问到通过 HTTP 传输的未散列密码？这只能通过 TLS 解决。
然后我将采用我今天拥有的解决方案，并希望最好。感谢您的宝贵时间。

标签： javascript php password-protection password-encryption password-hash

【解决方案1】：

您对在控制器之间劫持密码的担忧是多余的：

如果攻击者在密码在不同控制器之间传递时劫持密码，这意味着攻击者必须能够读取 PHP 进程的内存，这需要 root 权限。如果攻击者有 root 权限，你的问题就更大了，你的解决方案也救不了你，因为同样的攻击者也可以修改 PHP 文件来移除你的“保护”。

至于在通过 Internet 时劫持密码，唯一的解决方案是使用 HTTPS——无论你做什么 Javascript 加密/散列都是没有意义的，因为窃听者也能够在页面传输时更改页面并提供服务没有您添加的额外“安全性”的修改版本；关于在 Security.SE 上尝试保护没有 HTTPS 的登录表单有很多问题，请查看：

【讨论】：

问题是关于发布密码的第一步。除非使用 SSL，否则这是纯文本。
@kasperTaeymans - 如果密码通过 SSL 连接发送到网络服务器，那么它不会以明文形式发送
我并不是说您不必使用 SSL。我对此答案的评论是支持我的反对意见。
@AndréDaniel - 感谢您提供全面而翔实的回答。我会像今天一样去，并希望一切顺利。谢谢大家的时间。
@AndréDaniel - 嗅探器可能无法更改页面，在这种情况下，客户端散列将是有益的。它还将隐藏客户端和服务器之间的任何东西（例如代理、应用程序防火墙等）的纯文本密码，其中任何一个都可能受到损害。更不用说潜在的日志文件了。我还想补充一点，SSL 不是 100% 安全的。我不是在谈论破解密钥，但有一些方法可以规避它。以“sslstrip”为例。