在发送到服务器之前散列密码
当通过UTF-8编码的套接字传输发送密码时，如果我在发送数据之前使用MD5或SHA-1对密码进行哈希处理，它被认为是安全的？ 请记住，我打算比较SQL数据库中的散列密码。 我担心有人能够嗅探UTF-8中的哈希密码，然后解密UTF-8编码，并可以获得我的哈希密码，这可能会用于匹配我数据库中的密码。
如果客户端只是发送哈希密码，那么哈希密码就是“密码”：客户端只需显示要验证的字节序列。 如果攻击者可以嗅探到那么你的协议就注定了。
如果身份验证协议仅包含一段秘密数据（如果您愿意，则将其称为密码），则交换应在确保机密性（以便秘密数据无法被嗅探）和服务器身份验证（如此攻击者可能不会模仿服务器并说服客户向他发送秘密数据）。 这就是您从经典SSL / TLS隧道（ https:// URL，在Web上下文中）中获得的内容。
如果您无法通过服务器身份验证建立SSL / TLS隧道（即服务器具有客户端可以验证的证书），那么您可能需要使用带有挑战的身份验证协议：服务器发送一串随机字节挑战），并且客户端用通过密码和挑战串联计算出的散列值进行响应。 不要在家尝试做这个！ 要做到这一点非常困难，特别是当攻击者可以拦截通信（主动攻击）时。
更通用的答案是密码认证的密钥交换协议。 PAKE将密码密钥协议协议（如Diffie-Hellman）和客户端与服务器之间的双向密码身份验证相结合，即使密码相对较弱（攻击者无法获得足够的数据以“尝试”），也可以击败被动攻击者和主动攻击者。对于每次猜测，密码都不与客户端或服务器进行交互）。 不幸的是，很少有PAKE算法在数学描述之外被标准化，该区域是专利雷区。
那么，如果有人可以嗅探散列 - 他可以伪造授权请求并发送他已知的散列。
构建安全系统并不容易，你需要使用具有正确签名密钥的非对称加密来进行授权，以确保安全。
至少添加~100字节的随机盐，并使用SHA1 - 这样就难以暴力破解。
如果他们知道散列算法，他们可以暴力破解密码。 简单的（并非完全安全的）解决方案是使用挑战/响应，服务器发出一个随密码散列一起散列的随机字符串（“nonce”）。 这使得您的应用无法忍受您所描述的那种重播攻击。
有关更多信息，请参阅HTTP的摘要访问验证
链接地址: http://www.djcxy.com/p/21561.html上一篇: Hashing passwords before sending to server
下一篇: Should I hash the password before sending it to the server side?