Ozw*_*wel 12 passwords hashing
我想知道密码的输入是否在客户端/网络浏览器端或服务器端本地“转换”。
我很确定它在服务器端，但在这种情况下，它给我带来了一个担忧：这意味着您正在将密码发送给第三方。事实上，密码将通过安全通道传输到服务器，但最终服务器可以用它做任何它想做的事。自己计算哈希值并将其发送到服务器将使身份验证过程更加安全。
如果本地场景不可能，你能像我 5 岁一样解释一下为什么这是不可能的或者是个好主意吗？
use*_*686 32
\n\n我想知道密码的输入是否在客户端/网络浏览器端或服务器端本地“转换”。
\n
通常（使用常规的基于表单的登录）一切都在服务器端完成。
\n\n\n但在这种情况下，这给我带来了担忧：这意味着您正在将密码发送给第三方。事实上，密码将通过安全通道传输到服务器，但最终服务器可以用它做任何它想做的事
\n
是的，可以。因此，我们警告不要重复使用密码。
\n\n\n自己计算哈希值并将其发送到服务器将使身份验证过程更加安全。
\n
就其本身而言 \xe2\x80\x93 不，它不会。它将用一种风险换取另一种风险。
\n使用服务器端哈希，如果服务器的数据库泄漏（这种情况比 TLS MITM 发生的频率高得多），除非一一破解，否则这些哈希几乎毫无用处。通过客户端哈希，攻击者可以简单地开始发送这些哈希，就像它们是密码一样！现在，攻击者可以登录每个人的帐户，而不是一次性数据库泄漏，并且他们可以保留这些哈希值，并在数月或数年后使用它们登录。
\n（如果您让双方（首先是客户端，然后是服务器）对密码进行哈希处理，这仍然无法阻止恶意服务器存储客户端发送的哈希值并将它们重新发送到其他地方，就像密码一样。）
\n要真正避免这两个问题，您需要的不仅仅是散列；您需要一个稍微复杂的协议（例如，某种不像“HTTP 摘要”那样完全设计错误的质询/响应）。您还希望确保客户端发送的哈希不能在以后重复使用（甚至在不同的站点上），因为“重放攻击”是许多协议的问题。
\n例如，SCRAM 协议现在在 PostgreSQL 或 MongoDB 等非 Web 系统中有些常见。然而，对于 Web 开发人员来说，所有这些都比仅仅制作 HTML <form>\xe2\x80\x93 复杂得多，它们需要自定义 JavaScript 代码，并且通常需要与服务器进行多步骤交互。
似乎“既然我们无论如何都要添加 JavaScript”，网络总体上正在朝着根本不涉及密码的协议发展，例如使用公钥签名的 WebAuthn（有点像 SSH）。这并不一定意味着硬件加密狗，2FA \xe2\x80\x93“Windows Hello PIN”是操作系统提供的 WebAuthn 示例之一。
\nDmi*_*yev 17
自己计算哈希值并将其发送到服务器将使身份验证过程更加安全
不，接受哈希值而不是密码会使该过程的安全性大大降低。这与保留纯文本密码相同：如果攻击者窃取了包含用户名和哈希值的服务器数据库，他们可以立即以任何用户身份登录！
散列的全部目的是迫使攻击者反转单向函数：根据已知密码计算散列是微不足道的，而找到与给定散列匹配的密码则很困难。当哈希值被盗时，诸如字典单词之类的不良密码就会受到损害，因为计算超过 100'000 个单词的哈希值速度很快。好的密码仍然是安全的，因为要计算哈希值，您需要首先猜测密码。
是的，当您在网站中输入密码时，它会以纯文本形式传输到服务器，然后服务器上的脚本可以对其执行任何操作，甚至也以纯文本形式存储它。为了保护用户（大多数国家/地区的法律要求网站），他们对密码进行哈希处理并仅存储哈希值，但这并不意味着这种情况总是会发生。
但即便如此，如果密码哈希被黑客攻击，如果确实需要并且手头有足够的时间（假设他们也获得了安全哈希），它最终可能会被反转为纯密码。
那么这意味着什么，始终在每个站点上使用唯一的密码。最好使用带有随机密码生成器的密码管理器，这样您就可以只记住一个密码，而忘记其余的密码。有基于云的解决方案，也有本地解决方案，具体取决于您对云计算的不信任程度。
至于在本地计算哈希，技术上可以用javascript来完成，但它带来了巨大的安全风险。创建密码哈希时，您使用该哈希最终所基于的唯一哈希（安全哈希）。由于本地不知道这个唯一的哈希值，因此无法解密密码。如果您进行本地散列，那么突然服务器必须首先向您发送秘密安全散列以获取散列密码。然后黑客可以轻松解密任何哈希值。