反对认为 JS 加密没有意义的答案。似乎在这些答案里面，安全程度只有「安全」和「不安全」两种等级，是么。
先简单说下常用的 JS 加密（RSA）步骤：
服务端生成公钥私钥，下发公钥给客户端
客户端使用公钥（还有盐）对密码加密
把加密后的密码发送到服务端，服务端使用私钥解密拿到密码
对于攻击者来说，只要能够拿到 HTTP 明文，就可以在公钥下发时进行公钥或者加密方式的替换，拿到密码后解密，再使用服务器公钥加密密码明文，返回给服务端。简单几步就可以拿到密码明文了。
从根本上说，就是说只要中间人能够拿到 HTTP 明文，任何加密都是能够破解的。
然而客户端 JS 加密的意义在于它提高了拿到密码的成本。对于黑客来说，只要能监听到网络的 HTTP，把所有的 HTTP 请求直接保存到数据库，然后定期进行数据清洗，就能直接拿到一大批没有加密的密码，用这种方式采集密码，简直就是用大网捞鱼。
如果客户端采取了加密，「大网捞鱼」的办法就不奏效了。如果黑客需要拿到某个网站的用户密码，需要先分析加密方式，再针对性地代理和篡改 HTTP 内容，才能拿到密码。
加密之后，安全性提升了一个层次，可以把很多只会用工具的「黑客」拦在门外，当然是有意义的。
至于安全控件，因为它的加密算法是写在 native 里面的，而且公钥也可以直接内置到客户端，中间人无法篡改公钥，也就没办法拿到密码明文。而且它除了加密，还起到了一些其他的作用。自然有理由认为它比 js 加密更安全。
类似地，还有些网站全站 HTTP，只有登录部分用了 HTTPS，黑客完全可以在跳转登录页前进行劫持，把登录页的 HTTPS 入口链接替换成 HTTP 并进行 HTTP 劫持。所以说这种安全防范就是掩耳盗铃？在无法全站覆盖 HTTPS 的情况下，登录页能用 HTTPS 自然比不用好。
再举个相关的例子：HTTP 的网页经常会被运营商篡改，插入一些广告脚本。在没有能力进行 HTTPS 改造的情况下，有些网站会通过在响应头中添加 CSP （Content-Security-Policy）来防范。从理论上说，这种防范方式是没有作用的，因为运营商可以直接篡改你的 JS，更暴力的方式是删掉 CSP 头。但实际上，就目前来看 CSP 对于防运营商劫持还是有一定效果的。
终极方案还是全站 HTTPS，然而它也不是绝对的安全，如果下面任一环节出问题的话：
服务器安全没做好
加密算法和实现有漏洞，如 Heartbleed
客户端不安全，被安装了木马或者恶意插件
CA 不干净，或被安装了私有 CA
网页存在 XSS 等问题
