这不是一个好主意。但这不是 SRP 的问题。
SRP是一种密码验证密钥交换协议,双方通过该协议建立一个共享密钥,并通过另一个共享密钥进行相互身份验证。事情的美妙之处在于最初的共享密钥可能很弱(即人类用户可以记住的密码),但新的共享密钥不易受到离线字典攻击。
字典攻击是对人类兼容秘密的暴力攻击。攻击者尝试“潜在密码”,直到找到正确的密码。离线字典攻击是一种字典攻击,攻击者已获得足够的信息来在家中测试密码,而无需与目标系统进行任何进一步的交互;例如,如果攻击者拥有密码的哈希值,那么他可以通过对密码进行哈希处理并与已知的哈希值进行比较来尝试密码。离线字典攻击非常强大,因为没有什么能阻止攻击者通过专用硬件(GPU、FPGA、ASIC ......)、租用系统(商业云)甚至“借用电源”(空闲机器在一个大学网络、僵尸网络……)。
相反,如果离线字典攻击是不可能的,那么攻击者必须使用在线字典攻击,然后事情开始变得更好,因为诚实的系统可以限制它们的响应速度,甚至在太多失败后停止响应. 这就是带有 PIN 码的智能卡的行为:在几次错误的 PIN 码之后,它就会自行锁定。
PAKE 的重点是避免离线字典攻击。攻击者在想要测试潜在密码时必须与真正的客户端或真正的服务器对话。这对您的情况有一些后果:
PAKE 协议,特别是 SRP,自然地提供前向保密(也称为 PFS)。前向保密是关于保护过去通信的机密性,即使是针对后来设法窃取任何一方或双方长期存储的秘密值的攻击者。在 TLS-SRP 的情况下,唯一长期存储的秘密值是共享密码。
假设有一个过程P,攻击者在记录(被动)连接并随后窃取共享秘密(密码x)后,可以通过该过程解开连接的内容。如果这样的过程P不存在,则实现前向保密。但是,如果P存在,那么攻击者可以将其转变为离线字典攻击:攻击者只需“猜测”密码x ,并使用猜测的x值尝试过程P。如果有效,则猜测的密码x是正确的。
换句话说,如果一个 PAKE 协议不提供前向保密,那么从机械上讲,它也不提供针对离线字典攻击的保护,因此它不是一个“真正的”PAKE 协议。相反,良好的 PAKE 协议(如 SRP)必然提供前向保密。
上面的解释自然延伸到公共密码的情况。公共密码只是字典攻击真正有效的密码(攻击者第一次尝试就正确......)。因此,即使每个人都知道密码,您仍然可以保密。
然而,这一切都依赖于重要的细节。“前向保密”属性是关于被动记录连接并在之后尝试解密的攻击者。特别是,它没有提到主动攻击者。
如果每个人都知道密码,那么攻击者可能会伪装成假服务器,或假客户端,或同时伪装成两者;值得注意的是,攻击者可能会进行中间人攻击。然后,这样的主动攻击者可以拦截连接并查看所有数据流。由于 MitM 仍然双向转发数据,因此真正的客户端和服务器不会更明智。
这就解释了为什么我在这个答案的开头强调了“相互”这个词。当你说:
我们明确不想要身份验证,我们只需要保护每个会话的加密数据
那么这是一种自相矛盾的说法。你真正的意思是以下之一:
您不想要客户端身份验证(但客户端仍然必须保证它与正确的服务器通信);
您的使用环境使得攻击者无法活跃。
实际上,仅被动攻击者的情况极为罕见,大多数人只是假设攻击者无法更改传输中的数据,这只是妄想,并准备在某个时候粗鲁地觉醒。所以我们回到第 1 点:客户端应该仍然能够知道它是否与正确的服务器通信。在 SRP 中,共享密码是相互认证的基础。通过将其公开,您可以在两个方向上删除身份验证,这太过分了。
如果每个人都知道一切,就不会有任何身份验证的概念。但是 SRP 是基于这样的想法,即唯一的秘密是共享密码。因此,如果唯一的秘密实际上不是秘密,那么您将无法获得服务器身份验证。
如果您想要“未经身份验证”的通信(服务器不知道客户端是谁;但客户端仍然知道服务器是谁),那么 SRP 不是要走的路。相反,您将不得不使用“普通” SSL/TLS,其中服务器具有公钥/私钥对,并且客户端知道公钥,或者通过服务器的证书动态学习它(后者意味着证书验证,即是 Web 浏览器所做的,但也许您更愿意完全避免使用证书)。
摘要:是的,SRP 提供前向保密,即使密码是公开的。但是不,这不是一个好主意,因为前向保密并不是你真正想要的唯一东西。您还需要正常保密,如果您使用带有公共密码的 SRP,则无法针对主动攻击者进行保密。