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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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