我使用PKCS#5标准生成密钥,使用随机和唯一的salt和用户的输入密码。将此密钥视为“加密”密钥。
“加密”密钥用于加密随机AES密钥。每个用户都有一个与其配置文件相关联的AES密钥。
因此,用户的配置文件将包含以下信息:
我在问自己,同时拥有密码的散列、salt和加密的AES密钥是否危险。我99.9%确信这不是一个问题,但它能为攻击者掌握所有这些细节提供便利吗?
发布于 2011-05-31 14:27:03
只是为了确保我拿到了-你在储存:
所以..。AES密钥可能是真正的回报,因为它被用于加密通信或存储。
当您希望服务器使用密钥时,我猜这个过程如下:
然后,系统适当地处理AES密钥,做它需要做的任何事情,并从内存中删除AES密钥的任何副本,这样它就不会躺在任何地方。
事实上,我不认为这是一个弱点,但你已经把所有的事情归结为密码的优势。如果攻击者应该获得您的数据存储,那么他需要的但没有的是密码。如果用户有一个易于猜测的密码,那么攻击者将获得用户的AES密钥。
我想,如果是在分析这个系统的时候,我不会太担心这个问题--相反,我会开始探究用户密码是如何传递的,以及AES密钥在解密后是如何处理的--这些也是弱点,而且可能比哈希、盐类和加密密钥的后端数据存储更容易破解。
发布于 2011-09-29 19:45:11
如果攻击者想要破坏您的系统,他将尝试猜测密码。这意味着尝试潜在的密码直到一个“匹配”(这就是所谓的字典攻击)。匹配什么?攻击者可以通过两种方式查看密码是否正确:
攻击者会采取任何对他来说最简单的方法。PBKDF*函数包括一些使字典攻击更加困难的特性,即salt和可配置的内部迭代次数。迭代使得每个密码试用都很昂贵。salt阻止攻击者使用一个大的预计算哈希表(例如“彩虹表”)来优化事情。PBKDF2在这方面被认为是相当不错的(尽管bcrypt是可以说更好)。如果您的密码验证哈希不包括相同的功能,那么该哈希将是攻击者将使用的弱点。
简而言之,您的安全性将是密码验证散列和PKCS#5密钥派生中较弱的安全性。
更好的办法如下:
要验证密码,请使用存储的盐类S重新运行密钥派生函数,并对结果进行散列,以查看其是否与存储的h(K)匹配。如果您想解密B,只需使用重构的K,您就可以确保用于加密的密钥派生和密码验证哈希对字典攻击具有同等的抵抗力。
发布于 2011-06-07 02:55:17
我不认为你会想把哈希存储在AES密钥旁边。如果有人要访问原始加密的AES密钥、哈希和salt,他们可以很容易地强行从哈希中强制密码。鉴于今天的计算能力,蛮力强迫所有的字母数字密码只有6个字母需要2秒使用现成的GPU。像MD5、SHA1甚至SHA256这样的算法可以很容易地被强制使用今天的少量计算能力。
http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125
http://www.engadget.com/2010/08/16/gpus-democratize-brute-force-password-hacking/
http://www.insidepro.com/eng/egb.shtml
http://whitepixel.zorinaq.com/
因此,假设您没有将密码作为散列存储在它旁边。攻击者仍然可以强行强制加密的AES密钥,但如果用于计算加密的计算明显高于哈希,则不可能强制执行该加密。哈希算法(如MD5和SHA1 )是为速度而设计的。因此,这真的取决于哪一种算法在计算复杂度上更高,因为这个方案为你提供了多好的保护。
但是,这两种算法的长度可能都会降到密码<8个字符。一个7密码,混合大小写,所有符号只需7个小时在GPU上的某些算法。如果这些信息足够重要的话,等不了多久。
顺便说一句,盐渍没有帮助,因为它是存储在空中的,所以您必须假设攻击者可以知道它。盐渍所做的唯一的事情就是防止彩虹桌的攻击,这些攻击都是毫无意义的,因为我们可以用暴力来强迫它们。
https://security.stackexchange.com/questions/4199
复制相似问题