SRP还是WebCrypto挑战？

Question

对于一个新的网站(HTTPS与HSTS+HPKP)，我们希望限制登录访问的授权用户的设备。为此，在每个新设备上都生成了一个WebCrypto ECDSA公钥/私钥。服务器存储新设备的公钥并返回设备ID。浏览器保存在一个名为IndexedDB的设备中，私钥(不可提取)和设备ID。

当用户注册他的帐户或想授权一个新设备时，我们会问他这个设备的密码，但是我们不想将他的密码保存在服务器数据库中。

• 我们可以使用SRP协议并将salt &验证器发送到服务器，但是使用用户密码时，我们使用派生密码(WebCrypto PBKDF2或Argon2库)。
• 或者我们可以再次使用WebCrypto来创建新的ECDSA密钥，专门针对此设备上的用户，并在服务器上发送公钥。在浏览器上，我们使用AES-GCM算法将用户私钥(SHA-256(登录))存储在一个名为IndexedDB (SHA-256(登录))的用户私钥(wrapKey函数)中，对于密钥我们使用用户密码派生(WebCrypto PBKDF2或Argon2外部库)。然后要登录，服务器发送一个简单的随机字符串，客户端用这个新用户专用的私钥返回这个挑战的签名(所以他需要知道好的密码才能解开密钥)。

如果我们的DataBase被泄露：

• 使用SRP，验证器不能轻易地猜出用户密码，但我想我们需要向所有用户询问一个新密码。
• 对于WebCrypto，它只是一个公钥。用户不需要更改他们的密码。编辑:缺点是可以在客户端进行多个密码检查，例如，如果我知道我的受害者，我可以在JS控制台上尝试1000个可能的密码来打开用户私钥，而不需要与服务器联系。

当然，如果在浏览器上删除了IndexedDB，这就要求用户启动一个进程来恢复他的帐户(私人问题，通过电子邮件处理OTP，任何.它不是主题)，但这并不是WebCrypto选项所特有的，SRP选项也是如此，因为我们需要检测设备ID并检查它们的签名，以确保它是用户授权的设备。

为了获取信息，我们还在第一次身份验证挑战之后添加了U2F。

在我的具体情况下，您推荐使用SRP挑战还是这个WebCrypto挑战？

Answer 1

我提出这个解决方案是为了回答我的问题：

WebCrypto ECDSA密钥确实很有用，但是如果我们按照我的问题(用AES-GCM加密)中所解释的那样使用它，JS就有可能在受害者的浏览器上，在JS控制台中尝试上千个密码，知道它是否是好密码，而不需要与服务器连接。因此，最好不允许在没有服务器交互的情况下尝试密码。这就是为什么我的解决方案是只保留设备的ECDSA密钥，没有可提取的私钥，没有加密，并且对这个设备上的所有用户都是全局的。

SRP是广泛测试和广泛部署的，但是在DB泄漏的情况下，即使很难从蛮力中检索用户密码，也是可能的，因为攻击者拥有SRP盐类和验证器。因此，最好的方法是不要使用用户密码，而是使用一个随机OTP，并在每个成功的连接上更新它。

首先，如果设备没有存储的私钥：

• 生成新的WebCrypto ECDSA密钥
• 将此设备公钥发送到服务器
• 服务器为下一个请求返回一个deviceUUID和某种JWT。

当用户注册或自动更新新设备时：

• 生成512随机位的OTP
• 为导出的OTP生成128随机位的盐。
• 使用Argon2 512位，salt=derivedOTPSalt派生OTP
• 为SRP生成128随机位的盐。
• 为这个derivedOTP键创建SRP验证器
• 如果用户有U2F设备，请为该设备注册
• 向服务器发送deviceUUID、salt/ derivedOTP密钥验证器和U2F PublicKey。该请求由ECDSA设备私钥签名。
• 如果服务器接受用户注册，则请向用户请求此设备的密码。
• 为密码推导生成128随机位的盐。
• 使用Argon2 512位，salt=derivedPasswordSalt派生用户密码
• 创建一个蒙面密钥: OTP ^ derivedPassword (异或)
• 我们保存在一个被用户删除的DB IndexedDB/ save 256(登录)中: maskedKey、derivedOTPSalt、derivedPasswordSalt、u2f=(真/假)

然后，当用户想要登录时：

• 将登录名和deviceUUID发送到服务器，并请求SRP/U2F挑战(请求由ECDSA私钥签名，就像对服务器的所有请求一样)
• 如果设备的签名是确定的，服务器返回: challengeUUID、SRP盐分/B挑战和一个随机文本挑战与U2F设备签名(即使我们知道用户没有)
• 如果用户有U2F设备，请在质询上签名或生成随机位(以欺骗任何MITM)
• 请求此设备的用户密码并导出它(Argon2，salt=derivedPasswordSalt)
• 获取存储的maskedKey ^ derivedPasswordAttempt (XOR)的结果
• 从这个结果(理论上，我们得到原始的OTP)，然后用Argon2 / salt=derivedOTPSalt导出它，并由此生成A/M1SRP挑战答案。
• 我们还将按照注册方法准备下一个OTP。
• 发送到服务器: challengeUUID、U2F质询、SRP /M1挑战和下一个OTP的下一个SRP验证器和salt。

服务器可以确认它是良好的OTP、良好的ECDSA设备签名，如果用户有U2F设备，则确认为良好的U2F签名。如果一切正常，服务器将用下一个OTP验证器/salt替换旧的OTP验证器/salt，并返回新的授权JWT。

使用此解决方案，即使DB被泄露，也不可能检索真正的用户密码，只能检索派生的OTP，而且攻击者伪造用户身份是不够的，因为他还需要设备的私钥(和可能的U2F设备)。

对于MITM，他不能读取用户密码或OTP，但可以读取每个OTP验证器/salt。否则，这是不够的，因为他还需要私有设备密钥，并且可能是用户U2F设备。我们还使用HTTPS和HSTS+HPKP来防止MITM攻击。

对于具有受害者设备访问权限的攻击者，他可以使用设备的私钥，并且可以读取盐类和蒙面密钥，但这不应该有助于猜测密码，即使是在客户端受到暴力攻击时也是如此，因为他需要检查OTP对服务器请求是否正常。

此解决方案还在每次成功认证之后每次重新设置一个新的OTP。在DB泄漏的情况下，我们可以向所有用户发送推送通知，只要求他们连接到服务，以重新部署他们的OTP。

因此，该解决方案使用了受人尊敬的协议(SRP、ECDSA设备密钥、U2F验证、OTP、Argon2/PBKDF2 2)，并混合使用以提高安全性。

如果某个对等方能够审查此设计以指出任何故障点，这将是非常值得赞赏的:)