盐和密码 - 前缀或后缀

发布于 2024-07-21 00:28:45 字数 317 浏览 7 评论 0原文

这是一个关于需要散列的加盐短语的问题。

我想知道将盐放在短语前面或后缀是否更安全? 盐+短语或 短语+盐

我的问题来自这篇文章的评论关于MD5。 我不确定我是否理解作者评论背后的推理。

This is a question about salting phrases that need to be hashed.

I was wondering if it more secure to prefix the salt to a phrase or postfix it?
salt + phrase or
phrase + salt

My question comes from this comment on this post on MD5s. I am not sure I understand the reasoning behind the author's comment.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

苯莒 2024-07-28 00:28:45

盐加在前面还是后面都没有区别。

但以下因素将影响安全性。

  1. 尽管您的盐是否是私有的(如果是的话,它的私有程度如何?), 越私密越好。 这意味着,如果您可以避免将盐存储在数据库中,即使您的数据库受到损害,您也可以使您的系统免受暴力攻击。
  2. 您的盐是按值随机加盐的吗? 如果您的数据库遭到破坏并且您的盐存储在数据库中,这有助于防御彩虹表攻击。 注意:如果存储的密码足够长,它们就可以免受暴力攻击。
  3. 你的盐够长吗? 你的盐越长,你就越安全。

Whether the salt is appended to the front or the back makes no difference.

The following factors will affect security though

  1. Is your salt private (if so how private is it?). The more private the better. This means that if you can avoid storing your salt in your db you can make your system safe against brute force attacks even if your db is compromised.
  2. Is your salt random per value salted? This helps defend against rainbow table attacks if say your db is compromised and your salt is stored in the db. Note: if passwords being stored are long enough they can be immune to brute force attacks.
  3. Is your salt long enough? The longer your salt the more secure you are.
沉睡月亮 2024-07-28 00:28:45

当有人对盐的使用有疑问时,我担心这是因为他们正忙于(重新)发明他们本来就不应该发明的东西。 根据这个问题,我的建议是使用 HMAC。

When someone has a question about the use of salts I fear it is because they are busy (re)inventing things they really shouldn't be in the first place. Based on the question my recommendation is to use an HMAC.

那支青花 2024-07-28 00:28:45

当你消化盐时并不重要:前缀、后缀、中缀都会产生不同的哈希值,但达到了击败彩虹表或其他预哈希字典攻击的相同目的。

我认为该评论与 MD5 中的漏洞有关,而不是一般的散列。 我不明白细节,但它 与查找产生相同哈希值的两个前缀有关.

It doesn't matter when you digest the salt: prefix, postfix, infix all produce different hashes, but achieve the same purpose of defeating rainbow tables or other pre-hashed dictionary attacks.

I think that the comment has to do specifically with a vulnerability in MD5, not hashing in general. I don't understand the details, but it has to do with finding two prefixes that produce the same hash.

谁把谁当真 2024-07-28 00:28:45

与其他人所说的不同,这确实很重要! 如果你愿意的话,可以使用@einstein 的方式来使用HMAC

为什么前缀不好,因为可以计算到给定固定盐前缀的校验和的中间状态。 然后开始并行计算其余部分。 总之,phrase+saltsalt+phrase 更安全,但 HMAC(salt,phrase) 甚至更好。

相关阅读

unlike what others said, it does matter! and as @einstein if you care use HMAC.

why prefix is bad, because one can calculate the intermediate state of the checksum up to the given fixed salt prefix. then start calculating the rest in parallel. In summary phrase+salt is more secure than salt+phrase, but HMAC(salt, phrase) is even better.

related reading

天涯沦落人 2024-07-28 00:28:45

从技术上讲,这并不重要,只要盐是唯一的并且不容易被猜到即可。 只是不要像我一样犯储存盐的错误。

对字符串进行“加盐”的目的是通过比 MD5 哈希更加个性化和独特的方式对其进行加扰。 这样做的方法没有正确或错误之分,只要您是唯一知道它是如何工作的人即可。 无论哪种方式都会达到结果,即使生成的 MD5 哈希值与彩虹表对应,从而轻松破解密码。

Technically it doesn't matter, so long as the salt is unique and not easily guessable. Just don't make the mistake of storing the salt, like I did.

The purpose of "salting" a string is to scramble it in a way a bit more personal and unique than an MD5 hash will do. There's no right or wrong way to do it, just so long as you're the only one that knows how it works. It will achieve the result either way, which is to make the MD5 hashes generated not correspond with a rainbow table for easy cracking of passwords.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文