rambo92

@jianchang512 是的，脱裤的例子不对

@javalaw2010 感谢讨论。
这两点都是建立在传输通道不安全的基础上得出的结论，就是不光 http 不安全，也不放心 https 的安全性，认为都有可能被入侵而拿到传输的密码明文。
既然大家都认同 https 是安全且极难入侵的，那么我的观点的前提就不成立了。

第一个问题：能登陆，都拿到明文密码了，反过来就不行了（这也是 hash 存储的目的）；而前端 hash 的目的是防止在传输通道拿到明文，我前面说的脱裤的例子是错误的，无法证明这个手段和目的的合理性。

我的“前端需要 hash 传输密码”的观点，是建立在传输通道不安全（非源头，如 web 、iOS 等）的前提下，因为当时使用 http 的服务还有不少，加盐 hash 是为了防止传输通道被入侵时拿到明文密码；而在 https 是安全且极难入侵的传输通道的前提下，那我的观点的前提就不成立了。感谢普及 https 安全性的 v 友。

此外我有个问题希望和大家讨论一下：
密码是否应该在整个服务的流转过程中都是安全且不可接触的呢？
换句话说，如果服务端接收且打印了（或其他形式）明文密码，而这个信息可以被普通权限的开发者或员工接触到的话，作为用户是否可以接受呢？

@abelyao 无论你的还是我的，都是个人观点，可以给出论据来讨论，直接傻叉的话这话并没有分量。

我入行才 9 年多，也不算久，说 14 年入行也不是为了说明自己资历老就是对的，而是说明一下刚入行的时候就接受了这个观点的影响

@Trim21 没细看，太长了，只看了第一页的一半大概

@dode 嗯，个人观点

@ntedshen 感谢代码分析
另外贞操锁钥匙别外面这个比喻不太恰当，如果仅仅 hash 的话这么说没毛病，毕竟大部分用的 hash 函数都是 md5 ；
而加盐哈希，每个服务的盐不同，相同的密码得到的摘要也不同，更像是每个服务都有自己的贞操锁

@zero47 嗯，是的；
不过还有日志打印密码的骚操作。。。 这个素养还真不是每个程序员都有的啊；基于此，那么在架构设计时确定前端 hash 后传输，也可以防止这些情况的发生。

@mohumohu 挺有意思的，如果 Google 和 GitHub 也认为明文传输是合适的，那你们对；
而我坚持自己的观点。

@mohumohu 本帖的第二个问题被忽略了，大家都在讨论明文传输的问题


@june4 前端可以扩展到 Web 、iOS 、Android 等等

@FTLIKON 我没说过 MD5 是加密算法啊。