MD5密码两次
我知道 MD5 的安全性最近受到质疑，这就是很多人使用 salt 的原因（顺便说一句，我根本不明白这一点），但我想知道你是否想在 php 中轻松实现一个安全系统，你可以只 md5 两次吗？
就像测试> 098f6bcd4621d373cade4e832627b4f6> fb469d7ef430b0baf0cab6c436e70375
所以基本上：
$val = 'test';
$val = md5($val);
$val = md5($val);
这会解决整个彩虹安全问题吗？有没有一种简单/新手证明的方法可以在 php 中制作安全的数据库密码？
I know MD5's safety is under question lately and this is the reason a lot of people are using salt (I dont understand this at all btw) but I was wondering if you wanted to easily implement a safe system in php can you just md5 something twice?
like test > 098f6bcd4621d373cade4e832627b4f6 > fb469d7ef430b0baf0cab6c436e70375
So basically:
$val = 'test';
$val = md5($val);
$val = md5($val);
Would that solve the whole rainbow security stuff? Is there an easy/noob proof way of making secure database passwords in php?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
哈希两次没有什么实际意义，也没有多大作用。然而，一般来说，多重散列可能有一定的意义。例如，如果您散列足够多的时间，大约需要 100 毫秒（左右，取决于硬件），那么它可能会有所帮助。一点。它的基本思想非常简单：在正常登录中添加 100 毫秒是几乎明显的延迟 - 但如果您尝试构建类似用于字典攻击的表之类的东西，则需要乘以时间大约一千个（或者无论它的具体结果）开始产生真正的影响 - 一张通常可以在（比如说）一天内计算的表格，却需要几年的时间。这种差异已经足够大了，除了真正认真的攻击者之外，任何人在完成工作之前通常都会放弃（或者只是感到无聊）。
Salt 是一个完全独立的工具。使用它并不能弥补底层哈希函数的弱点。这里的想法是，字典攻击的表大小变得更大（例如，对于一字节盐，大256倍）。盐通常不保密，但它相对随机，因此进行字典攻击的攻击者不能只按原样散列每个单词，而必须考虑每个可能的盐值。存在重复的风险：它解决了（大多数）人们选择密码的弱点，而不是散列函数本身的弱点。
Hashing twice makes little real sense and doesn't accomplish much. In general, however, multiple hashing can make some sense. For example, if you hash enough times to take something like 100 ms (or so, depending on hardware) it can help a little. The basic idea of it is pretty simple: adding 100 ms to a normal login is a barely noticeable delay -- but if you're trying to build something like a table for a dictionary attack, multiplying the time by something like a thousand (or whatever exactly it works out to) starts to make a real difference -- a table that you could normally compute in (say) a day, takes a few years instead. That's enough difference that anything but really serious attackers will often give up (or just get bored) long before they finish the job.
Salt is an entirely separate tool. Using it does not make up for weakness in the underlying hash function. The idea here is that the size of a table for a dictionary attack becomes substantially larger (e.g., for a one-byte salt, 256 times larger). The salt is not normally kept secret, but it's relatively random, so an attacker who's doing a dictionary attack can't just hash each word as-is, but has to take each possible salt value into account. At the risk of repetition: it deals with a weakness in how (most) people pick passwords, not any weakness in the hash function itself.
如果您不相信 MD5，您可以使用 哈希来尝试更高的算法() 函数：
在我看来，哈希两次是没有意义的。
编辑：修复了最后一行代码中的拼写错误。
If you don't believe in MD5, you can try a higher algorithm by using the hash() function:
In my opinion it does not make sense to hash twice.
EDIT: Fixed typo in last line of code.
无论您是否使用 MD5 算法...
不，攻击者始终可以拥有两个彩虹表（一个用于额外级别的哈希值，另一个用于密码）。并来自 我的另一个答案：
您使用盐可以使攻击者更难获取您的密码，因为这样他就需要知道盐，以便可以使用它来计算密码的哈希值。
Whether or not you use the MD5 algorithm...
No, an attacker can always have two rainbow tables (one for the extra level of hashes, and one for the passwords). And from another answer of mine:
You use a salt to make it more difficult for the attacker to get at your passwords, because then he would need to know the salt so that he can use it in computing the hashes for your passwords.
安全地存储密码很棘手，这里发布的大多数建议都不准确。因此，我将遵循 Thomas Ptacek 关于该主题的广泛引用的帖子：http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you -需要了解-s.html
Storing passwords securely is tricky, most the advice posted here is not accurate. So I will defer to Thomas Ptacek's widely cited post on the subject: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
根据记录，我评估
它相当安全。秘密就在于盐。
然而，md5 很短，因此并发的机会“高”（1.208.925.819.614.629.174.706.176 = 32^16，32 个单词，每个单词一个十六进制）
For the record, I evaluated that
Its pretty safe. The secret is in the salt.
However, md5 is short so the chances of concurrences are "high" (one in 1.208.925.819.614.629.174.706.176 = 32^16, 32 words with an hexadecimal each one)