我正在尝试为 Web 应用程序创建登录系统，但我遇到了一些问题。我使用带有 128 位随机盐的 sha2-512 哈希将密码存储在我的数据库中。
但是，我目前使用 html 表单将密码以纯文本形式发布到我的应用程序中，无论是在创建帐户时还是在用户登录时。我知道这是错误的。
我需要在客户端中对密码进行哈希处理吗？如果是这样，我如何考虑当前生成并存储在数据库中的盐？
注意：我这样做是为了学习不要在生产系统中使用
【问题讨论】：
标签： authentication hash passwords salt
最好的选择通常是使用 SSL。如果您确实需要在客户端进行哈希处理，我会这样做：
这是安全的，因为它确保传输的散列对于请求是唯一的（它使用单个请求的随机盐），因此将来不能通过再次发送散列来伪造登录。向客户发送他们存储的盐并不危险，因为假设密码破解者可以访问存储的盐（如果他们可以访问数据库）。需要两个哈希值来防止您将密码存储为明文。
【讨论】：
您应该使用 SSL 来传输加密的密码，这样中间人就无法拦截数据包并读取正在发送的凭据。即使您在客户端预先对密码进行哈希处理，中间人仍然可以使用该值来伪造身份。
不过，我真正关心的是 SHA-512 的使用。很多人使用加密散列来存储密码，但流行的观点忽略了一个非常重要的点：这些散列设计是为了快速。也就是说，成为 SHA（或类似）散列的要求之一是能够在嵌入式硬件上快速散列大型文档。
这与您想要的密码存储完全相反，因为它允许高性能 GPU 上的专用例程以惊人而可怕的速度暴力破解密码！
这就是为什么开发了一些专门构建的密码存储散列。我一直在使用的是Bcrypt，它的速度足够慢，可以阻止暴力攻击，可以调整以适应未来更快的硬件，并且可以为您处理盐渍。
【讨论】：
在客户端上散列密码需要在客户端上使用盐。这也暴露了您的算法，以便在客户端非常容易地进行黑客攻击。最好的做法是通过 SSL (HTTPS) 执行此操作，以便对整个事务进行加密，并且仅在服务器上进行身份验证。
即：您的用户 ID 和密码是从客户端加密传输的。 Web 服务器解密数据并将其传递给您的服务器端身份验证功能，您可以在其中查找用户和关联的盐，执行密码 + 盐 + 散列并将其与存储的散列进行比较以进行匹配。这意味着根本不需要从服务器传输哈希和盐。
【讨论】：
您确实需要在传输密码的任何页面上使用 SSL。如果您尝试在客户端加密它们，它将使用 javascript 并且非常容易进行逆向工程。
【讨论】：