security - 非破坏性散列后处理是个好主意吗?

标签 security hash

在存储之前对哈希字符串进行某种非破坏性的后处理(重新排序)是个好主意吗?例如:

$hash = strrev(hash($algo, $data . $salt));

其他例子:

$hash = hash($algo, $data . $salt)
$hash = strrev(substr($hash, 0, (int) ($length / 2))) . strrev(substr($hash, (int) ($length / 2)));

而不是简单地:

$hash = hash($algo, $data . $salt);

换句话说:

考虑到破解者不知道哈希值是如何转换的,前两个示例会导致比第三个示例更少的可破解哈希值吗?

不是说我会strrev我的哈希值,这只是我能想到的最简单的例子来说明“非破坏性”在这种情况下的含义: 在不减少算法 key 空间的情况下对哈希进行后处理。

寻找的答案:

  • 伙计,用盐来避免彩虹表等等 - 虽然彩虹表是相关的
  • 像这样重新散列你的散列 hash(hash(hash($data))) - 问题不是关于重新散列
  • 请不要推出自己的加密货币 - 这不是我要说的
  • 不要运行自己的加密货币。 - 这也无济于事

我实际上正在寻找的答案:

This is (is not) a good idea because of ...reasons... Here is some example about why you should (should not) do this: ...example... Also, read this ...paper, article, post, link to a research... that proves my point.

最佳答案

让我们尝试分析所提出的算法,就好像“非破坏性后处理”是一个 secret 函数,从一些可能的函数空间中获取。

从这个角度来看,后处理有点像 key ,整个算法是一个带 key 的散列(像HMAC)。以下是该算法的一些关键点。

key 散列可以抵抗已知明文攻击:如果攻击者知道许多后处理散列的输入值,应该仍然很难找到“ key ”。但是,如果后处理很简单,例如您示例中的 strrev,攻击者可能很容易找出“ key ”。

您必须仔细设计这些功能的空间。

编辑:如何将分组密码应用于散列结果?至少这样,您可以利用经过仔细审查的非破坏性函数空间的优势。

关于security - 非破坏性散列后处理是个好主意吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23961206/

相关文章:

css - Stylus - 散列导致错误

perl - 在不遍历整个哈希的情况下在子哈希中查找键

java - 为什么 JPasswordField.getPassword() 会创建一个包含密码的字符串?

security - 安全领域的定义

hash - 使用 UUID 拆分在目录中均匀分布文件

database - 这个可扩展的哈希解决方案有什么问题?

Perl 在 hash of hash 中搜索一个值并重新分配给另一个 hash

php - 我的 php "Remember me"系统安全/实用吗?

security - 客户端登录 - 如何在客户端安全地存储凭据?

windows - 语言中立的文件系统访问规则