为了使用SRP 协议启动密钥交换,客户端发送用户名,以便服务器可以查找 salt 和密码验证器。有没有一种简单的方法来改变它,使窃听者无法发现用户名?
我认为额外的 Diffie-Hellman 可以解决这个问题,但是 SRP 协议非常相似,我想知道是否有一种方法可以在没有太多开销的情况下将其合并。
为了使用SRP 协议启动密钥交换,客户端发送用户名,以便服务器可以查找 salt 和密码验证器。有没有一种简单的方法来改变它,使窃听者无法发现用户名?
我认为额外的 Diffie-Hellman 可以解决这个问题,但是 SRP 协议非常相似,我想知道是否有一种方法可以在没有太多开销的情况下将其合并。
Diffie-Hellman 在这里帮不上忙:活跃的攻击者可以使用经典的MITM并查看应该受 DH 密钥保护的任何数据。他只会“从外部”看到 SRP 交换,但仍会知道用户名。
连接用户的非匿名性是密码验证密钥交换算法的一个相当基本的属性。此类协议可以抵抗离线字典攻击,因为双方在协议的早期阶段都做出了特定于密码的承诺。
在 SRP 中,服务器应该选择一个随机的b,并将B = v + g b发送给客户端。假服务器不知道v但想学习它,因为知道v允许离线字典攻击(即,在攻击者自己的计算机上“尝试”密码直到匹配,而不再与用户或真实服务器交互)。然而,由于离散对数的困难,攻击者无法知道与给定B匹配的v和b,除非他选择v和b并计算B从这些价值观。攻击者不能回顾他过去的消息并思考这样的事情:“好吧,让我们假设我应该使用v'而不是我使用的v ,因为那是客户端可能已经理解的内容”;如果他这样做了,那么他就失去了b的知识,并且在不知道b的情况下,他处于随后的 Diffie-Hellman 交换的“外部”(SRP 在其核心仍然是一个带有钟声的 Diffie-Hellman)。这样,B是一个承诺:服务器在发送B时承诺给定的密码相关值v,因为除非他继续使用v的确切值,否则它将无法从协议的其余部分获得任何有用的信息。这就是 PAKE 魔术发生的地方:这种承诺确保攻击者必须与用户或真实服务器或两者进行交互,以获取他猜测的每个密码。这严重降低了字典攻击的效率,这就是 PAKE 协议的重点。
由于服务器必须在协议开始时(在身份验证实际发生之前)提交给定的密码相关值,因此服务器必须知道我们正在谈论的密码,因此“明文”发送用户标识符。
为了保持用户对窃听者的匿名性,服务器必须首先由客户端以独立于用户的方式进行身份验证,这是您从带有服务器证书的基本TLS隧道中获得的,但是如果您使用 SRP,不是吗?避免使用证书?此外,在与 Internet 相关的设置中,窃听者仍将获知用户 IP 地址,这在许多情况下几乎与名称一样好。
如果你只是想防御被动窃听者,那么有一个简单的方法:在客户端和服务器之间建立一个加密连接,然后通过这个加密连接发送所有的 SRP 消息。
在实践中,一种实用的方法是在客户端和服务器之间建立 SSL 连接或 VPN,并通过此加密隧道发送所有内容。如果客户端不检查服务器的证书,那么这对于被动窃听者是安全的,但对于主动攻击者(中间人)则不安全。
如果客户端确实检查了服务器证书,那么这对于主动攻击者和 MITM 攻击也是安全的(取决于客户端验证服务器证书的能力)。
您始终可以使用加密(通常是 SSL 等传输加密)保护内容(甚至是登录凭据)。
使用 DH 或类似的东西滚动你自己的加密基础通常是一个坏主意;使用已建立的东西(同样,例如 SSL)有助于保护您免受您可能没有预料到的陷阱。例如,使用 DH 生成的密钥进行对称加密的问题在于它是未经身份验证的加密。客户端与某人建立了安全连接,但他不知道该人是服务器还是 MITM 攻击者。SSL 中基于证书的身份验证可以防止这种可能性。
因此,建立从客户端到服务器的加密连接,使用公开签名的证书用于通用用途,或者如果您的应用程序是唯一的客户端,则生成您自己的签名证书。然后,一旦建立加密链接,然后发送您的登录凭据等。然后您最好保持加密连接,因为开销最小并且增加的安全性很重要。