Sql 在发送到服务器之前对密码进行哈希处理

当通过UTF-8编码套接字传输发送密码时，如果在发送数据之前使用MD5或SHA-1散列密码，是否认为是安全的？请记住，我计划在SQL数据库中比较哈希密码。我担心有人可能会嗅探UTF-8中的哈希密码，然后解密UTF-8编码，并获得我的哈希密码，该密码可能用于匹配我数据库中的密码。

如果他们知道哈希算法，他们可能会强行使用你的密码。简单（但并不完全安全）的解决方案是使用质询/响应，服务器发出随机字符串（“nonce”）与密码散列一起散列。这使得你的应用程序不受你描述的重播攻击的影响

---

有关更多信息，请参阅HTTP的“如何检查数据库端的密码？”

如果您存储密码的非盐散列并将其与输入进行比较，则可以嗅探并重用散列密码

这就好像您正在以纯文本形式将密码本身存储在数据库中一样

如果您害怕嗅探，请使用质询-响应协议进行身份验证，但在这种情况下，机密将存储在数据库中（并且任何有权访问数据库的人都会知道）

---

或者，您可以通过受保护的通道（

SSL

）发送纯文本密码，但您必须安装一个证书，这很可能会花费您一些钱（如果您使用的是供应商提供的列表中的权限，即您客户的浏览器不会抱怨的权限）

，如果有人可以嗅探散列-他可以伪造授权请求并发送他已经知道的散列

构建安全系统并不容易，您需要使用具有正确签名密钥的非对称加密进行授权，以确保安全

---

至少添加~100字节的随机salt，并使用SHA1——这样会更难使用暴力。

Hm，如果你说的是“适当的”散列，这意味着它将“加密”你的密码，因此它将无法解密，因为散列是单向函数，而解密它——这需要一段时间，某种程度上是很好的

如果您关心密码嗅探器，您可以将其提升到下一个级别—使用私钥/公钥加密。服务器应该向客户端发送一个质询（用于加密的公钥），客户端使用它进行加密，只有服务器知道如何解密。对于同样数量的钻头，它提供了更多的保护——也就是说，需要更多的肌肉来用蛮力将其敲碎

---

签出。

如果客户端只发送散列密码，那么散列密码就是“密码”：客户端只需要显示以进行身份验证的字节序列。如果攻击者能够嗅到这一点，那么您的协议就注定失败

如果身份验证协议只包含一段机密数据（如果您愿意，可以称之为密码），那么交换应该发生在确保机密性（以便无法嗅探机密数据）和服务器身份验证的传输介质中（这样攻击者就不会模仿服务器并说服客户机向他发送机密数据）。这是从经典的SSL/TLS隧道（Web上下文中的

https://

URL）中得到的

如果无法使用服务器身份验证建立SSL/TLS隧道（即服务器具有客户端可以验证的证书），则可能需要使用带有质询的身份验证协议：服务器发送随机字节序列（质询）客户端会用密码和质询串接计算出的哈希值进行响应。不要在家中尝试此操作！正确操作非常困难，尤其是当攻击者可以截获通信（主动攻击）时

---

一个更通用的答案是协议。PAKE将加密密钥协议（如Diffie Hellman）和客户端与服务器之间的相互密码身份验证结合在一起，以一种击败被动和主动攻击者的方式，即使密码相对较弱（攻击者无法获得足够的数据进行“尝试”）密码（每次猜测都不与客户端或服务器交互）遗憾的是，很少有Pakes算法在数学描述之外被标准化，并且该区域是一个专利雷区。

是否有C++中的库，它正确地使用了认证和一个挑战？使用SSL并将服务器证书与嵌入在程序中的散列进行比较。在2017，Sh1不再是一个加密散列ALGO。里思。