当通过 UTF-8 编码的套接字传输发送密码时，如果我在发送数据之前使用 MD5 或 SHA-1 对密码进行哈希处理，是否被认为是安全的？请记住，我计划比较 SQL 数据库中的散列密码。我担心有人能够嗅探 UTF-8 中的散列密码，然后解密 UTF-8 编码并获得我的散列密码，该密码可能用于匹配我数据库中的密码。
【问题讨论】：
标签： sql security sockets hash passwords
好吧，如果有人可以嗅探哈希 - 他可以伪造授权请求并发送他已经知道的哈希。
构建安全系统并不容易，您需要使用非对称加密和正确签名的密钥进行授权以确保安全。
至少添加约 100 字节的随机盐，并使用 SHA1 - 这样会更难暴力破解。
【讨论】：
如果客户端只是发送散列密码，那么散列密码是“密码”：客户端只需要显示以进行身份验证的字节序列。如果攻击者可以嗅探到，那么您的协议注定失败。
如果身份验证协议只是提供一段秘密数据（如果您愿意，可以将其称为密码），那么交换应该发生在确保机密性的传输介质中（这样秘密数据就不会被嗅探）和服务器身份验证（这样攻击者就不会模仿服务器并说服客户端向他发送秘密数据）。这就是您从经典 SSL/TLS 隧道（https:// URL，在 Web 上下文中）获得的结果。
如果您无法通过服务器身份验证建立 SSL/TLS 隧道（即，服务器具有客户端可以验证的证书），那么您可能需要使用带有质询的身份验证协议：服务器发送一个随机序列字节（质询），客户端以通过密码和质询的串联计算的哈希值进行响应。不要在家尝试做这个！很难做到正确，尤其是当攻击者可以拦截通信（主动攻击）时。
更通用的答案是password-authenticated key exchange 协议。 PAKE 结合了加密密钥协议协议（例如 Diffie-Hellman）和客户端和服务器之间的相互密码验证，以一种可以击败被动和主动攻击者的方式，即使密码相对较弱（攻击者无法获得足够的数据来“尝试”）每次猜测时不与客户端或服务器交互的密码）。不幸的是，除了数学描述之外，很少有 PAKE 算法被标准化，而且该领域是一个专利雷区。
【讨论】：
如何查看数据库端的密码？
如果您存储密码的未加盐哈希并仅将其与输入进行比较，则可以嗅探并重用哈希密码。
这就像您将密码本身以纯文本形式存储在数据库中一样。
如果您害怕嗅探，请使用质询-响应协议进行身份验证，但在这种情况下，秘密将存储在数据库中（并且任何有权访问数据库的人都知道）。
或者，您可以通过受保护的通道 (SSL) 以纯文本形式发送密码，但是您必须安装一个证书，这很可能会花费您一些钱（如果您使用的是供应商的授权 -提供的列表，即您的客户的浏览器不会抱怨的列表）
【讨论】：
如果他们知道哈希算法，他们可能会暴力破解您的密码。简单（而且不是完全安全）的解决方案是使用质询/响应，服务器发出一个随机字符串（“nonce”）与密码散列一起进行散列。这使您的应用不受您所描述的那种重放攻击的影响。
有关详细信息，请参阅 HTTP 的 digest access authentication
【讨论】：