腌制密码哈希
我正在尝试为Web应用程序创建一个登录系统，但我坚持了几个要点。 我将密码存储在我的数据库中，使用带有128位随机盐的sha2-512哈希。
然而，我目前使用html格式将密码以纯文本形式发布到我的应用程序中，无论是在创建帐户还是用户登录时。我知道这是错误的。
我需要在客户端散列密码吗？ 如果是这样，我如何考虑当前生成并存储在数据库中的盐？
注：我这样做是为了学习不用于生产系统
在客户端散列密码需要在客户端使用salt。 这也暴露了你的算法在客户端非常容易黑客攻击。 最好的做法是通过SSL（HTTPS）执行此操作，以便整个事务处理都被加密，并且身份验证只发生在服务器上。
即：您的用户ID和密码从客户端加密传输。 Web服务器解密数据并将其传递到服务器端身份验证功能，您可以在其中查找用户和相关联的salt，执行password + salt + hash并将其与存储的散列进行比较以进行匹配。 这意味着哈希值和盐值永远不需要从服务器传送。
最好的选择通常只是使用SSL。 如果你确实需要在客户端进行散列，那我就是这么做的：
这是安全的，因为它确保传输的散列对请求是唯一的（它使用单请求随机盐），所以只需再次发送散列，登录不会在将来被伪造。 发送客户端存储的盐并不危险，因为假定密码破解者可以访问存储的盐（如果他们可以访问数据库）。 需要两次哈希以防止您将密码存储为明文。
您应该使用SSL传输加密的密码，以便中间人无法拦截数据包并读取正在发送的凭证。 即使你在客户端预先密码，中间人仍然可以使用该值来伪造身份。
然而，真正令我担心的是使用SHA-512。 很多人使用加密哈希来存储密码，但流行的观点忽略了一个非常重要的观点：这些哈希被设计得很快。 也就是说，成为SHA（或类似的）散列的要求之一是能够快速地在嵌入式硬件上散列大型文档。
这与密码存储所需要的完全相反，因为它允许高性能GPU上的特殊例程以惊人而可怕的速度暴力破解密码！
这就是为什么一些特制的密码存储哈希已经开发出来的原因。 我一直使用的是Bcrypt，它的速度足够缓慢，可以防止暴力攻击，可以在未来为更快速的硬件提供更多的配合，并且还可以为您处理盐渍化。
链接地址: http://www.djcxy.com/p/17879.html