密码管理器安全

Question

我正在为学校编写密码管理器，我想知道我应该改进或改变什么。 它是这样工作的：

为了保存主密码，我在SHA3-512 之上创建了一个带有PBKDF2 512bytes output 散列密码的文件。使用随机的128byte 盐和随机的迭代次数（这是问题的重点）。 所有这些数据都保存在文件中，并使用伪随机生成器进行加扰，该生成器的种子是从密码本身生成的（这种方式更难获得盐）。

然后存储密码的文件用AES 256加密，从用户PC伪唯一标识符生成salt。

当用户选择密码时，要求是：最少 10 个字符并且不在100.000 最常用密码列表中（我在互联网上的某个地方得到了这个列表，可能已经过时了）

好吧，我有几个问题：PBKDF2 的当前标准迭代计数是多少？ PBKDF2 输出字节长度重要吗？我的意思是更长的长度 = 更高的安全性？

更长的盐会给我额外的安全感吗？

它保存在文件中的盐，因此“可能”检索它，有没有比仅仅加扰字节更好的方法来“隐藏”它？

Answer 1

PBKDF2 当前的标准迭代次数是多少？

没有。标准文档中未指定迭代计数。在不惹恼用户的情况下尽可能多地使用。请记住，这通常是通过设置目标时间量（对于实际硬件）来确定的，例如 0.1 秒到 2 秒，然后尝试多次迭代计数以更接近该标记（如果你不这样做，请使用二进制搜索'没有可以中止的带有日志记录的 PBKDF2 实现）。

当然，你不应该自己定义迭代次数，而是让用户定义它（Keepass 就是这样）。它基本上是一个有目标时间的基准。

迭代次数是 PBKDF2 中安全性的主要驱动因素，如果您请求的输出不超过底层哈希函数的输出大小，则基本上是攻击者的减速。

PBKDF2 输出字节长度重要吗？我的意思是更长的长度 = 更高的安全性？

是的，这很重要，但只是在一定程度上。如果输出很小，比如 64 位，那么比 128 位输出的散列更容易找到冲突（一些散列到相同输出的输入）。这就是为什么现在不应该使用短散列函数的原因。任何输出 256 位的东西都可以。请注意，可以实现 SHA-512，使其在 SHA-256 的 64 位平台上运行得更快。

更长的盐会给我额外的安全感吗？

不，盐可以区分同一密码或密钥的多次使用。使用 same salt 将使窃取密码数据库的攻击者能够同时暴力破解所有用户的密码，而不是一个接一个。拥有 64 位或 128 位的盐就足以防止彩虹表的生成（但大的迭代计数基本上可以解决这个问题）。

只有当您认为攻击者可以同时对您用户的多个密码容器进行离线暴力攻击（从而预先侵入多个用户计算机）时，才有意义。

p>

它保存在文件中的盐是“可能的”检索它，是 有没有比仅仅加扰字节更好的方法来“隐藏”它？

不，盐不应该是秘密的。它的唯一目的是输出的随机化，尤其是在使用相同密码的情况下。只需从良好的随机源生成随机盐并按原样存储即可。当然，如果您使用经过身份验证的加密（AES-GCM 或类似的），那么您应该将盐作为附加的经过身份验证的数据传递，以检测（恶意）操纵。

---

有用的资源：@​​987654321@Cryptography 上的标签。