当我在服务器和客户端中实现 PBKDF2 时,我的理解是(可能是错误的,抱歉),服务器将加密/散列密码保存在数据库中,用户通过网络发送他或她的密码,然后它由服务器检查有效性。
这基本上是正确的。设置帐户时,用户发送并发user
送到pass
服务器。服务器存储user
然后PBKDF2(pass)
丢弃pass
. 登录时,服务器会查找该user
列并与PBKDF2(pass_as_submitted)
设置帐户时存储的值进行比较。如果它们匹配,则对用户进行身份验证。
我是否只依赖网络库或 SSL 来保护这些信息?
在你所说的那种情况下,是的。
在密码客户端执行 SHA2 散列,然后将其发送到服务器,然后检查 sha2 与 PBKDF2 散列是否是明智的?
不,这里的问题是您只是将您保留的内容从用户密码更改为用户密码的哈希值。可以读取数据库的攻击者仍然知道它。
(这是有原因的,这比知道密码要好一些,尤其是在密码重用的情况下。但是,这些并不能证明这种方法的合理性。)
值得指出的是,SHA2(password)
不匹配PBKDF2(password)
。
专业人士通常会做什么样的这些事情?
首先,使用 TLS(又名 SSL)。在客户端和服务器之间建立良好的加密连接是第一要务。对于网站,您应该在每个页面上都使用 TLS,而不仅仅是在发送密码时。至少它必须在登录页面和接收用户名和密码信息的请求中使用。
应该正确设置您的 TLS 连接:它应该在适当的情况下使用 HSTS(并且它是一个网站)。它应该避免过时的算法(如果可能,只支持 TLS 1.1+)。它应该使用适当的密码模式。
除此之外,这取决于您的用例。也许值得实施两因素身份验证 - 无论是使用 TOTP 还是 SMS 代码或类似的。也许您应该查看没有密码的登录,例如使用客户端 TLS 证书或 OAuth2 令牌。也许您应该使用现有的身份验证库,例如 Kerberos。也许您需要查看密码策略以确保用户设置了正确的密码或密码短语。
这些问题很复杂,取决于您的用例。考虑它们是大多数人没有迈出的第一步。使用 PBKDF2 是一个很好的开始,但没有通用的答案。如果可能,请专家进行安全分析。如果没有,开源加上一些促销通常可以让人们看到它。最坏的情况,阅读安全性,查看OWASP Top 10并考虑系统的每个部分。尽可能使用专家制作的现有库。如果你必须自己动手,你可能做错了。