浏览器记住密码功能真的安全吗

存在浏览器里的密码使用起来是非常方便的，大家应该也都习惯了密码自动填写的便利，但是这些密码是如何存储的，以及浏览器批量存储这些密码真的安全吗，这都是需要进一步考量的，正好之前了解过主流的两类浏览器（及使用这两类浏览器内核）的密码管理协议，在这里做一下分享。

1.3 更改/找回密码

当用户更改其密码（即他们仍然知道旧密码）时，或当用户忘记密码时，需要重置账户和密码。下面将分别讨论两者情况：

当需要利用旧密码重置密码时，需要完成下图流程：

其主要协议流程为验证用户身份，之后用户使用旧密码将存储在服务器的wrap(kb)解密，然后使用从新密码派生的新密码重新包装kb生成新的wrap(kb)。

对于找回密码，用户首先需要访问fxa-content-server（即服务器）上的页面，服务器向用户发送一封带有恢复代码的电子邮件，然后在用户单击该电子邮件中的链接，利用存储的邮件地址来验证自己的身份，从而重置密码。

具体而言，当用户申请重置密码，服务器将相应的帐户标记为“待恢复”，为该帐户分配一个随机密码ForgotToken，创建一个恢复代码，并向用户发送电子邮件，其中包含URL（指向fxa-content-server）、passwordForgotToken和恢复代码作为query-args。

当用户单击链接时，加载的 fxa 内容服务器页面会将令牌和代码提交到 API。当服务器看到匹配的令牌和代码时，它会分配一个backtoken并将其返回到提交它们的客户端（页面）。然后，客户端可以创建新的密码并重复创建账户时的密码创建流程，如下图所示：

值得注意的是，一旦重置密码，将会丢失所有B类数据，这避免盗取邮箱的攻击者获得用户的所有口令，用户只能得到存储的A类数据。

这个设置是必要的，如果B类和A类不分开存储，那么同时也会有攻击服务器的攻击者，一旦得到服务器控制权，就可以解密A类，但是无法解密B类口令。

1.4 安全性分析

本协议使用基于 HKDF 的派生密码用于保护本协议中请求的内容。HKDF 用于创建多个与消息长度相等的随机字节，然后将这些字节与明文进行 XOR 运算以生成密文。然后从密文计算 HMAC，以保护消息的完整性。之所以使用该方案是因为HKDF首先可证明计算安全，其次易于指定且易于实现（只需要实现HMAC和异或操作）。

那么盗号🐶该如何盗号呢？首先，攻击者可以暴力枚举kb，但这意味着他们必须对要测试的每个猜测的密码进行1000轮PBKDF和其他操作，这是计算上困难的，用自己家的电脑得算上几万年。

其次，盗号🐶可以通过web漏洞如果控制了服务器（如利用中国蚁剑等webshell工具获得服务器webshell），获得了文件读写权限，那么攻击者也无法解密wrap(kB)。此时A类数据将会被窃取。

第三，即使盗号🐶利用盗取的邮箱重置用户密码，也无法访问B类数据（关于ab类，在文章开头我们定义了，它代表数据的安全级别），B类数据会丢失。此时A类数据将会被窃取。

2.Chrome浏览器的记住密码

Chrome密码管理器采取了与firfox完全不同的安全策略，其将密码和加密过的数据均存储在用户本地，以windows为例，Chrome通常将使用windows API CryptProtectData 直接将加密后的口令存储在AppData\Local\Google\Chrome\User Data\Default\ Login Data，将密码存储在AppData\Local\Google\Chrome\User Data\ Local State。

Chromee的立场是主密码提供了一种虚假的安全感，保护敏感数据的最可行保护方式是要取决于系统的整体安全性。所有，为了执行加密（在Windows操作系统上），Chrome使用了Windows提供的CryptProtectData API，该API允许已经用于加密的Windows用户账户去解密已加密的口令。所以也可以理解为主密码就是Windows账户密码，即只要登录了Windows账号，Chrome就可以解密口令，并导入密码管理器中。

就是说，如果攻击者通过脚本（对了，就是我之前那篇文章提到的伪入库的脚本）获得了本地电脑的账号口令，那么你所有的密码都会被带走。换言之，chrome不需要像firfox那样对你的秘钥安全负责，你对自己的秘钥直接负责。

我自己写了个脚本测视了一下我的chrome，果然直接跑出了密码，确实有点离谱：

所以最后结论就是大家还是要谨慎对待记住密码这个功能，特别是使用chrome浏览器同时还经常伪入库是盒友，不然就只能：