@zkeeper 虽然不是 985 但还是是比一些末流 985 要好的，而且有地理位置加成（北京），就计算机通信类而言，中西部地区、东北地区的 985 不如北邮。

代码上都要做解耦，讲究代码复用呢，为啥要反其道而行？

跨日了，需要定义和处理边界问题。

目测长得不漂亮

这些文章获得了 0 个喜欢。。。笑尿，这还不如不总结呢

不给映射表做个鸡巴，这后端已经不是懒了，完全没有团队意识

房租这个根本没有实施性可言。房东: 要上税？下个月房租涨 50%，爱租不租不租拉倒

@cyrbuzz 抱歉打错了，hazh->hash
先说结论，客户端散列是有意义的，但不在于防属于信道安全的劫持问题，而是防端点安全问题。针对楼主的分场景讨论一下。
不可信传输信道下（例如 http ），就密码散列而言，没啥卵用，毫无安全性，中间人可以直接篡改密码字段，改成由他构造的密码。当然如果前端用 rsa 加密，那光有加密还不行，还要做签名防篡改。用户名和密码的加密了也不够，用户的敏感操作（比如付款）也要加密，内容一多就有性能问题，要引入更快的对称加密和密钥协商。这基本上等于手撸一套 ssl，成本太高，而且非常容易出 bug。
可信传输信道下（例如 https，在这里不讨论 https 本身的安全问题，如果讨论的话就成了拜占庭问题了），这么做也颇有意义。解决了传输信道的安全问题就万事大吉了吗？还有端点的安全问题。客户端和服务端总有一个加密和解密的过程：客户端加密之前的步骤得小心翼翼，上钩子防键盘窃听，内存保护，各层的日志得仔细审核防止记录密码，还有就是楼主质疑的这点，服务端不完善的话（就算确认了对端的身份，也要假设对端存在泄露风险），要对密码进行散列，而且直接散列都不行，要加盐散列，防止用户密码泄露后被字典攻击和在别的网站密码重放。服务端解密后的过程也是，拿到密码也要再进行一次散列（这里就是包含密钥的加盐散列了），日志层要仔细审核防止记录密码，还要保证散列密钥、私钥的安全。随着计算性能的提高，加密和散列算法或者短密钥也会暴露出问题，如何及时替换老旧算法或者老旧密钥也是个问题。
扯远了，总之客户端做密码散列也是有意义的，意义不在于劫持问题，而是端点的安全问题，区分传输信道的安全和端点安就很好理解了。

@zzzzzzZ 技术讨论都这么戾气，全世界的人都欠你？

@zzzzzzZ 睿智如你，已 block

@cyrbuzz http 这种明文传输的，黑客想干啥都行，密码 hazh 了也没用，直接重放攻击，管他内容是啥，劫持下来，原样发过去照样登录。要在 http 下防止这些，这几乎等于自己写了一套 ssl/tls，没准还考虑不周全有漏洞，所以还不如用 https 呢。

这叫示臀，意思是叫你快摸它屁股（滑稽

@usingnamespace 抱歉确实我说得太笼统了，为了学个正则去学一遍编译原理确实走偏了。就正则而言，只需要学编译原理里的词法那里就行了。再深入下去就是自动机，这个看个人需求了。相对于强记硬背那些鬼画符，从编译原理里选择性的学习是没错的。你觉得呢？

下个 runasdate，设定以 25 日及之前运行 xshell5 就行

学习编译原理。正则的三种基本运算是连接、选择和闭包，其他运算的可以视为语法糖了，虽然表达力有限，大部分需求没啥问题了。加一个非运算。

@Fraotisc 动不动就上升到喷人，怪不得这么喷子属性，原来是资深软粉。