从原理上分析，把明文进行 100 轮 [SHA512->SHA256] 这样哈希计算，随机性会比直接 SHA256 更差吗？运算后结果可能性不都是 2^256 种吗？照这么说的话加 salt 也会影响随机性？

记得在本站一篇讨论在前端给用户密码加密是不是脱裤子放屁的帖子中有人说把明文变长后 hash 会一定程度上影响随机性，从而导致安全性降低，当时我就很怀疑这种说法，觉得毫无根据，当时没空发帖，现在又想到了这个问题，并且想改成更极端的情况，先更长的 SHA512 再 SHA256 再 SHA512 ，重复 100 轮。

drymonfidelia

111 天前

我的想法既然每一位单独发生改变都一定会影响 SHA256 的运算结果，SHA256 运算结果的每一个 bit 应该都是等可能性的，不管怎么对明文取样，只要每一个明文 bit 取样的权重一致，都不应该影响随机性（不懂怎么表达，大概是这样）

YGHMXFAL

111 天前

目的呢?

如果想校验数据完整性,只需要选择强壮地摘要算法 HASH 一次即可

如果想增加攻击者穷举密码的计算成本,有专门为这一场景设计地、专用定制硬件也望洋兴叹地[慢 HASH]算法,例如 scrypt/argon2

应该是在 SOF 看过一帖,这一套[多轮 HASH]或者类似地[多种算法嵌套 HASH]都是不推荐地方案,原理我也没看懂,结论就是会增加碰撞地可能性,也就是说反而降低了安全性

cxtrinityy

111 天前

emmm ，哈希是摘要，不是加密，不可逆的，密码 hash 可以避免你保存的用户密码被人脱库直接暴露吧，所以你也不需要保存用户密码，下次拿了密码再哈希一遍对上了就是密码正确
随机性这个没看明白，哈希和随机性有啥关系？算法是公开的呀，同样的算法，同样的输入，只会有同样的输出，sha256 碰撞的可能性已经很小了吧，只要不是常用的那些密码，一般很难撞上。暴力轮询也只是把常用的密码 hash 后记下来作为词典查询罢了。
至于明文长度，不知道你说的原帖具体咋说的，不过应该和 hash 结果分布没啥关系，毕竟不管啥明文也是要先切割补位的

drymonfidelia

111 天前

@YGHMXFAL #2 目的是前端 hash 满足 /t/1025454 这里面的一部分人对形式主义安全的要求（他们觉得服务端不应该收到能还原回明文的密码，但是前端加密完全阻止不了被劫持或者被恶意浏览器插件直接注入 js 读取输入框里的明文密码）。服务端收到客户端的提交的 hash 后加盐二次 hash 后再入库防止数据库泄露了有人使用数据库里的 hash 来登录网站。

julyclyde

111 天前

多轮 hash 更容易碰撞吧
你都明知道后一轮的输入是更小的集合了

geelaw

111 天前

用函数作用于一个输入，那么输出是固定的，没有任何随机性。如果输入本身是随机的，那么作用函数之后依然是随机的，但熵不会增加，而且非常明显的例子是把具有 1024 bits 熵的输入用楼主提出的两种方式作用，得到的结果熵必然不能超过 256 bits 。

当然，经过函数作用后，“计算熵”可以增加，然而标准模型下很难分析 SHA-512 和 SHA-256 对输入的计算熵产生何种影响。

只考虑抗碰撞的话，多个函数复合的抗碰撞能力当然不超过最里面的那个的。

0o0O0o0O0o

111 天前

多轮 hash 不增加熵，所以只要输入固定就不影响"随机性"，影响的只是攻击者的成本
https://www.google.com/search?q=site%3Acrypto.stackexchange.com+KDF+entropy

gbadge

111 天前

两轮肯定会比一轮安全，拿被脱裤的站举例，相当于加盐处理了

FengMubai

111 天前

@drymonfidelia #4 这个问题可以规约成：你是否认为服务提供方有安全义务保障当自身安全系统被攻破时，用户在其他站点的数据不受影响？

drymonfidelia

111 天前

@FengMubai 你说的是在前端 hash 明文密码吗？理由我已经给了，就算在前端加密了，攻击者如果破解了我平台的服务器，也可以往登录页面插入记录明文密码的恶意 js ，把密码 post 到他们的服务器，因此前端加密并不能阻止保障当自身安全系统被攻破时，用户在其他站点的数据不受影响。就算在前端没有加密（目前绝大部分网站都是这样），只要我数据库里存的密码是 hash 过的，自身安全系统被攻破时，用户在其他站点的数据也不受影响。

FengMubai

111 天前

@drymonfidelia #10 插入恶意代码这件事，至少你还可以拔网线

FengMubai

111 天前

理论上会降低随机性，但实际上不会。

首先，你的随机性是由输入源决定的，它的空间大小是无穷的。经过一轮哈希后，空间大小变成了 256 位（以 SHA256 为例），理论上随机性是下降了的。但是，目前 SHA256 还没有发现碰撞，所以实际上没有降低随机性。而如果你用的 MD5 ，那实际上肯定也是降低了。

为什么要做多轮哈希？为了增大彩虹表攻击的难度

rekulas

111 天前

作为一款加密算法,如果随机性都做不到稳定那也太拉了,怎么可能被选为标准

不会增加随机性,但会增加安全性

jim9606

111 天前

主要问题就是多轮迭代会缩小值域，你要是用短的摘要（例如只有 64bit 的 MD5 ）就会比较要命，使用截短 hash 也会有一样的问题，如果不幸没有使用等长时间复杂度的 hash 校验方法也会削弱 hash 的保护能力。
还有考虑密文泄露的场景（服务器数据库泄露），如果没加 salt ，攻击者可以预先构造彩虹表，你这种 100 轮 hash 是用同数量级的性能代价提高攻击代价，用 100 倍计算复杂度换 100 倍攻击难度，这是不划算的，还是加 salt 好。
直接原文拼接 salt 有导致长度拓展攻击的问题，所以不是搞密码学的还是老实用封装好的 HMAC 就好了。

gbadge

111 天前

试想一下一个 80 亿用户规模的数据库将密码按照 OP 的说法处理，就算被脱裤，离线暴力破解的难度也会加大，首先对方可能不会想到，其次解密工作量翻倍，安全肯定是更安全

restkhz

111 天前

经常看到这种争论，我平时很少在这种争论中说话。

回复 OP 一楼：理论上，对于 SHA-256 这种成熟可靠的算法，多次迭代不会有问题。实际上很多地方有在用这种做法。
回复 OP 四楼：我也同样不认为在实践中对于普通业务 https 下还前端 hash 密码有多好的安全性，除非是某些特别场景。前端加密能保护的东西太有限了。
回复 OP10 楼：是这样的。如果服务器被 pwn 那么最重要的还是数据库里的东西。该加盐的加盐就好了。

HTTPS 后前端 hash 到底保护啥了？防止 HTTPS 被破解？还是服务器那边 https 解密后的过程？如果我都拿下服务器了我为什么不注入脚本钓鱼？

我看过 11 楼在另一个帖子里自己发明的方法，是好的想法，但有点鸡肋。拔网线了意味着黑客同时也不可能嗅探到 https 流量。只能对着之前拖的库里的 hash with salt(应该有两层 salt) 干瞪眼。但是可能只有极其极端情况下才有用。其实同样的，我曾经也想过一样的问题。但是我的对策是 pwd+salt+challenge-response 。
另外纠正一下，真正对彩虹表有完全克制作用的是 salt 而不是迭代。迭代只是减缓破解速度。

实践上呢？
黑客拖库后通常不是搞什么集群 FPGA ，ASIC 暴力破解，而是直接提交给某个老牌网站批量查。
没经验的搞不出来就放弃了，有经验的会看代码，然后发现批量破解成本太高，破半天搞出几个弱密码。
一般黑客也不会劫持 web 服务软件去读用户请求，还不如上一个 xmr 矿机搞 ddos 闷声发大财(其实基本都是 bot 在做)除非你的用户价值非常非常高，高到别人愿意花多少万来专门搞你的用户。

唉，有时候禁止用户用弱密码反而可能是一个不错的方案。

dzdh

111 天前

一次 hash ，是任意字符输入的组合的 hash 结果。还不限长度。

一次 hash 后，可选字符只剩下了 0-9a-f ，还限制长度。

无论多少轮，最后碰撞只剩下 0-9a-f 还限定位数的范围。

就单从概率来说也并不比一次 hash 安全。

dzdh

111 天前

如果是密码，bcrypt/scrypt/argon2(i|d) 足够。

校验完整性，任何 hash 一次足够。

tool2dx

111 天前

正常的 hash 算法，大部分都是随机的。个别 bit 随机性测试可能结果稍微弱一点，但是这种是完全可以忽略的。

密码 hash 还有一个问题，就是没加 padding 。以至于时间足够，是可以暴力推导的。比如用户密码 abcd ，你加 5 层 sha256 并加盐，结果也恒定，可以通过彩虹查找表得到明文。但如果用户名密码加了随机 padding ，就如同 rsa 加密标准那样，密码从 4 字节变成了 256 字节，那就推不出来了。

和 1 个字节 hash 后，和 1G 文件 hash 后，hash 长度一致，蕴含的内容意义完全不一样。