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

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

@drymonfidelia 我猜前端加密应该是避免中间人攻击？之前做金融行业的网站的时候，前端就会对密码采用动态加密以防止中间人攻击，为什么这么做？因为真的有人被攻击了。。。

f_1(f_2(f_3....f_n(input))) 等价于存在一个 g(input)
g 的离散性直觉上取决于 f chain 中的离散性分布.

直观的例子就是传统机器学习所谓收敛 local minimal 的概念.

比如如果你其中一个或者几个 f 在空间分布式存在某种形式的倾斜,那么逻辑上就是多余某个 f_k 的输出存在一定的偏向性.

极端情况累积下,可能存在你的 f chain 的等价形式 g 就是一个常数.

会减小随机性，摘要是多对少的，你用少的结果再去摘要，值域只会更少

本质上仍旧是成本跟安全的平衡，客户端弄个 Hash 就加几行代码的事，就能提升整条链路的安全性，何乐而不为呢？我不明白这事有什么可争的。

@rekulas #21 应该是有影响随机性的。比如先 hash 成 256 个字符的 A ，A 再 hash 成 512 字符的 B ， 这时候 B 最多只有 16^256 种结果，但是如果是不限制输入，B 有 16^512 种结果

多轮 hash 的目的是增加攻击者的计算成本。就本身分布和单轮 hash 是一样的

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

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

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

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

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

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

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

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

回复 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 在做)除非你的用户价值非常非常高，高到别人愿意花多少万来专门搞你的用户。

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

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