我正在为学校编写密码管理器，我想知道应该改进或改变什么。 这是它的工作原理：
要保存主密码，我会在PBKDF2 512bytes output之上创建一个密码为SHA3-512的密码。使用随机128byte盐和随机数量的迭代（其范围是问题的关键）。
所有这些数据都保存在文件中并使用伪随机生成器进行加扰，该生成器是从密码本身生成的（这种方式更难获得盐）。
然后存储密码的文件是AES 256加密，盐是从用户PC伪唯一标识符生成的。
当用户选择密码时，要求是：最少10个字符，而不是100.000最常用的密码列表（我在互联网上的某个地方获得此列表，可能已过时）
嗯，我提出的问题是：PBKDF2的当前标准迭代次数是多少？
PBKDF2输出字节长度是否重要？我的意思是更长 - 更安全吗？
更长的盐会给我额外的安全吗？
将盐保存在文件中，以便它可以＆＃34;可能＆＃34;检索它，是否有更好的方法来隐藏＆＃34;它不仅仅是加扰字节？
答案 0 :(得分：2)
PBKDF2的当前标准迭代计数是多少？
没有。标准文档中未指定迭代计数。尽可能多地使用而不会烦扰用户。请记住，这通常是通过设置目标时间量（对于实际硬件）来确定的，例如0.1秒到2秒，然后尝试多次迭代计数以便更接近该标记（如果你不喜欢，则使用二进制搜索） ＃39;有一个带有日志记录的PBKDF2实现，您可以中止）。
当然，你不应该自己定义迭代次数，而是让用户定义它（Keepass就是这样做的）。它基本上是一个具有目标时间的基准。
迭代次数是PBKDF2中安全性的主要驱动因素，并且基本上是攻击者的减速，前提是您没有请求更多输出，即基础哈希函数的输出大小。
PBKDF2的输出字节长度是否重要？我的意思是更长 - 更安全吗？
是的，这很重要，但只有一点。如果输出很小，比如说64位，那么比具有128位输出的散列更容易找到冲突（一些哈希到相同输出的输入）。这就是现在不应该使用短哈希函数的原因。输出256位的任何东西都可以。请注意，可以实现SHA-512，使其在SHA-256的64位平台上运行得更快。
更长的盐会给我额外的安全感吗？
不，有盐可以区分同一密码或密钥的多次使用。使用相同的盐将使窃取密码数据库的攻击者能够对所有用户进行暴力破解。密码同时而不是一个接一个。具有64位或128位盐足以防止彩虹表的生成（但是大的迭代计数基本上处理了这一点）。
如果您认为攻击者可以同时对用户的多个密码容器进行离线暴力攻击（因此预先分成多个用户计算机），那么只有盐才有用。
不，盐不应该是秘密的。它的唯一目的是输出的随机化，特别是当使用相同的密码时。只需从良好的随机源生成随机盐并按原样存储即可。当然，如果您使用经过身份验证的加密（AES-GCM或类似），那么您应该将salt作为其他经过身份验证的数据传递，以便检测（恶意）操作。将盐保存在文件中，以便它可以＆＃34;可能＆＃34;检索它，是 有更好的方法来隐藏＆＃34;它不仅仅是加扰字节？
有用的资源：pbkdf-2上的Cryptography标记。