即使我使用的是 HTTPS，是否应该在客户端使用 hash(password + salt) 方法对密码进行哈希处理？还是应该在它到达带有内置函数的 SQL SERVER 2008 R2 时对其进行散列？谢谢你。
问问题
95 次
4 回答
1
为什么要在客户端散列？这是用 Javascript 编写的单页应用程序吗？即使这样，您也必须使用某种服务器端语言连接到数据库（ASP.NET？PHP？）。在服务器端进行加盐和散列。客户端对我来说很糟糕......由于某种原因，如果你有逻辑和随机生成发生在客户端，那么加盐/哈希过程似乎更容易受到攻击。我无法指出具体的攻击——但推送到客户端似乎是一件不必要的事情（除非你可能无法获得 SSL）。
无论您是使用服务器端语言还是直接在数据库中进行，都不是特别重要。我更喜欢在代码中进行计算，然后将最终哈希发送到 SQL。使用内置 SQL Server 函数很烦人，并且版本之间存在问题 - 而且您的代码永远锁定在 Microsoft 领域。
TL;DR在服务器端进行，而不是在客户端，而不是直接在数据库中。如果您希望在发送之前通过线路加密明文密码（绝对应该），则 HTTPS 是必需的。
于 2012-11-15T23:35:55.097 回答
0
据我所知，如果有人发现安全漏洞并从数据库中窃取密码列表，密码的加盐（也）很有用。如果加盐，几乎不可能用彩虹表之类的方法找回清晰的密码。否则，它们可能会被破解。
于 2012-11-15T23:35:45.970 回答
0
如果您假设 HTTPS 已损坏，则会出现许多安全后果。基本上一切都崩溃了。
不要这样做。这是浪费你的时间。以更好的方式使用它，例如开发用户关心的功能。
只需在服务器上进行标准哈希和加盐，尽量不要发明新的安全方案。
于 2012-11-15T23:36:23.393 回答
0
如果您使用 SSL，客户端和服务器之间的通信将被加密。
问题的后半部分稍微复杂一些。尽管 SQL Server 具有内置加密功能，但它面临的问题是任何有权访问数据库的人都可以使用它。
如果您在代码中加密并将加密版本发送到数据库，它可以在数据库受损的情况下为您提供保护 - 他们可能已经侵入您的数据库，但他们无法解密数据。
所以我的答案是......既不是客户端，也不是数据库 - 在两者之间的代码中加密和加盐！
于 2012-11-15T23:36:37.420 回答