Mar*_*o B 5 security hash md5 cryptography
嗨我有关于MD5 Hash/Salting的问题.
我最近阅读了很多关于散列和盐析的内容,我明白我应该为每个密码使用不同的盐,并且我不应该使用像用户名这样的东西,因为理想情况下盐应该是完全独特的.但我不明白为什么建议将这个盐与密码一起存储在数据库中？
如果攻击者获得哈希和盐,这不是很糟糕吗？我理解攻击者更难,因为独特的盐确保他无法检查所有密码的单个计算哈希值.但是,保持盐的一部分隐藏不是更好吗？
我想到将盐分成两部分.第一部分像往常一样存储在数据库中,第二部分(较小)部分在我的应用程序中硬编码.攻击者几乎不可能获得完整的盐,因为他必须渗透应用程序服务器和数据库.
这是一个好的解决方案吗？盐仍然是独特的,但所有的盐都以相同的顺序结束.
Yah*_*hia 10
攻击者"被允许"知道盐 - 你的安全必须以一种方式设计,即使知道盐,它仍然是安全的.
盐有什么作用？
Salt使用预先计算的"彩虹表"帮助抵御暴力攻击.
对于攻击者来说,盐使蛮力更加昂贵(在时间/内存方面).
计算这样一个表是很昂贵的,通常只有当它可以用于多个攻击/密码时才会这样做.
如果您对所有密码使用相同的盐,则攻击者可以预先计算此类表,然后将密码暴力强制为明文...
只要您为每个密码生成一个新的(最好的密码强)随机盐存储哈希没有问题.
根据您使用MD5的方式,这是一个弱点,因为MD5不再被视为"加密安全"
如果你想进一步加强安全性
你可以多次计算哈希值(散列哈希等) - 这不会花费你太多但是它使得暴力攻击/计算"彩虹表"更加昂贵. ..请不要自己发明 - 有经过验证的标准方法,请参阅http://en.wikipedia.org/wiki/PBKDF2和http://www.itnewb.com/tutorial/Encrypting-Passwords -with-PHP-for-Storage-using-the-RSA-PBKDF2-Standard和http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
使用这种机制现在是强制性的,因为"CPU/GPU时间"(可用于彩虹表/暴力等攻击)正变得越来越广泛(例如,参见亚马逊的云服务进入前50名的事实)世界上最快的超级用户,可以被任何人用于相对较小的数量)!
将盐分成2块,一块硬编码/常量和一个独特的部分不推荐!
根据所使用的算法,这可能是帮助攻击者破坏安全性的弱点.我强烈建议不要这样做,除非你能从数学上证明它不会削弱你的安全性(这很难做到恕我直言).
如果您正确实施安全性,攻击者根本不知道您的完整盐是没有问题的......
更新(根据评论):
RFC 2898是PBKDF2的重要参考.在4.1节中,它谈到了向盐中添加一部分
salt应该包含明确区分不同操作和不同密钥长度的数据
这有恕我直言与OP所要求的无关.RFC讨论了密钥长度等信息,并与随机盐一起作为附加部分加入.这与包含描述其包含的数据的特定方面的标题部分的文件格式非常相似.这不会削弱安全性,并且在需要不同系统之间的互操作性的情况下可能非常有用.
相比之下,OP要求的基本上只是在DB中存储一部分盐,同时保持应用程序中其他(较小)部分硬编码,这意味着DB中的盐不完整...这样做意味着丢失熵盐(即8位恒定的64位盐实际上只能像56位盐一样安全),这反过来又会削弱盐提供的安全性(至少对于我现在可以想到的任何算法都是如此) )......这与OP意图(增加安全性)相矛盾.
更新2(根据与owlstead的讨论):
您可以使用一个完全存储在数据库中的独特且随机的盐,使用PBKDF2在明文BEFORE哈希中添加一些"秘密"(可以在您的应用程序中进行硬编码)...尽管它可以帮助解决安全问题默默无闻的 IMO.