关于登录接口，除了明文传输密码之外还有更好的选择吗？

[fangshouyibo777]

我观察了几个网站，大多都是明文传输，这样会不会有一些潜在的风险？

[lusi1990]

TLS 加密了, 中间看不到明文

[learningman]

有 https 你怕啥，再说 js 是明文的，你在前端做加密不是掩耳盗铃

[94]

前端加密就是骗鬼😂

[eason1874]

前端加密倒也不完全是掩耳盗铃，毕竟有些情况是监听软件自签证书安装到系统，这时候 HTTPS 就等于 HTTP 了。

把密码取哈希值再提交，有意义，不过意义不大，只能防普通抓包。如果中间人有意针对，可以在网页插入一段劫持 JS 直接监听你的输入。

[fangshouyibo777]

我是知道 TLS 可以在传输层加密的，但如果是明文，浏览器插件是不是可以抓取的到？

[Aliencn]

@liupengpeng TLS 保证传输过程中加密。如果客户端不安全，那么即使发送数据前加密也是可以被拦截到的。

[xarthur]

@Aliencn 客户端不安全基本上没有什么办法了，客户端不安全相当于用户自己把密码给别人了。

[listnodeptr]

密码按照监管要求，必须散列后再提到服务器端，hash 是不可逆的，防的是网站服务器方拿到明文密码，当前大厂都是按照这个要求的，我举几个风险的例子

1. 公司 SRE 维护服务器时，可能从 nginx 上 dump 出明文密码，在大厂，那么多 SRE 谁要是随便操作失误一下拿到一堆用户明文密码，直接能拿出去卖了
2. 密码即使散列加密后也属于机密数据，不允许流转大数据分析平台，但我们始终需要一部分人在帐号中台去触及这些数据的存储备份传输分析维护，这些人创业初期是推心置腹的好兄弟来承担重任，后面公司上市后人员换了一波又一波，你怎么知道哪个时间点哪个 admin 不会看着明文密码动坏心思？哪天不知道啥网站啥地方漏密码了，你会怀疑自己公司每一个人么？
3. 监管有时候会来调查案子，某用户智商捉鸡别的网站被骗了，然后觉得是帐号被盗了，密码大概是泄露了网上明文能查到，然后有人联合用户造谣非说你网站被黑泄露的，好了请你协助调查一下明文密码是不是你公司网站泄露的？嗯？散列不能恢复？调查结束，辟谣就好了

正确解法就是强制要求前端加密（散列），不过不是骗鬼，是防止内鬼骗你

[dogking2]

存在中间人攻击风险，使用 https 或者对传输过程关键字做加密（比如：rsa ）

[icyalala]

前端加密对于"传输安全"而言是没有什么意义。。
监听软件或者自签名证书，如果能抓到明文，当然也能抓到 JS 或知道网站算法，解密当然也没问题。
不加盐的 hash 提交，相当于把 hash 本身当做密码，同样也没什么意义。

前端加密在这些方面可能有些意义：
保护用户隐私。看看这些年密码泄露的事件吧，只要明文传输到服务端，整个链路里的各个节点、Log 记录、内存 dump 等等都有可能把明文留下来。
增大逆向难度，但是这个收益不大。

[ZeroDu]

前端 aes/des 加密 -> 后端解密并处理密码规则是否合理 -> md5+salt+各种 hash 规则入库

[yimity]

@listnodeptr 那你后端不要存明文密码就可以了么。

[icyalala]

@yimity 在入库前，只要有明文传输，都有可能导致明文被记录，
看看前两年的 Twitter 和 Github，都是中途某个 Log 把明文记下来了，类似这种事情在大公司发生得还很频繁。。

[eason1874]

@yimity #12 你没理解，他说的是服务器中间件能接触到密码，就是还没到后端的组件，比如不涉密的部分运维能接触到的 CDN 、SLB 等等。

说到这个我才想起来确实有这种情况，不同层级保密等级不一样，密码明文直接提交的话，所以层级的日志都能记录到，看来确实有必要在前端取一遍哈希。

[qrobot]

@eason1874 #14L

在这里骗鬼啊， 前端进行 HASH 的密码。 等于你的密码就是 hash 的值。 运维人员接触到了 hash 密码，直接用过接口测试工具，例如 postman 或者 curl 然后直接参数的密码就是这个 hash 的值， 一样可能登入。 如果为了安全唯一的可能性，就是防止撞库。 防止运维拿着这个密码去碰撞。

[codingguy]

@liupengpeng #5 要说浏览器插件的话，输入时候不就能抓到了，哪还需要到传输阶段

[eason1874]

@qrobot #15 当然不是防运维登录用户账号，是防运维得到用户密码明文，大部分用户只有几个密码，泄露了是肯定波及其他平台的。

防运维登录可以上 AES 甚至 RSA 加密表单字段。

[lonewolfakela]

@qrobot 但是 hash 泄露也只是你这家的服务完蛋了，如果是明文密码泄露，用户在其他地方如果用到同样的密码的话很可能一块儿完蛋。
另外实在不行你也可以把密码和日期之类的放一块儿 hash，这样就算泄露了第二天也就没法用了。

[cslive]

学学银行怎么做的

[qrobot]

@eason1874
@lonewolfakela
#17 #18

```
但是 hash 泄露也只是你这家的服务完蛋了，如果是明文密码泄露，用户在其他地方如果用到同样的密码的话很可能一块儿完蛋
```

那就是撞库， 撞库严格来说不算是三方系统的安全问题。（ PS： 准确说被撞的那个系统安全上不作为存在的安全问题）

密码其实是存在泄漏的可能，无论是第三方撞库，还是说人为的泄漏密码，这些都算作系统安全。

如果真的要预防这个问题。 我认为应该从以下方向去考虑

1. 在登入的时候判断用户是否在常用的 IP 地址中
2. 通过浏览器指纹来判断这是否是用户经常访问使用的浏览器
3. 在登入的时候需要采用 RSA 非对称加密算法，将 指纹和密码进行加密， 正式环境的私钥和开发测试的要进行区分
3. 如果有异常情，例如 IP 和浏览器指纹不一致， 并且区别很大（需要用户通过手机或者邮箱进行二次确认）

[jim9606]

通常建议 PIN 用先 KDF(PBKDF2 、scrypt)处理之后再发送。尽管不能防范重放攻击，但这样服务器群就不会接触到 PIN 本身。服务器不可能泄漏它没有的东西。运维日志泄漏密码（哪怕只是在内部泄漏）是很有可能的，而且外界还可能不知道。

国内有些网站会用手工 RSA 处理 PIN 后发送，主要是防范被动记录，例如用在不加密的 HTTP 和合规的 MITM 代理。

[zm8m93Q1e5otOC69]

前端加密就是脱裤子放屁

[sarices]

怕不安全可以用一次性密码啊

[lonewolfakela]

@qrobot 我们这里讨论的当然不是“被撞的那个系统”而是密码泄露的源头的那个系统啊……只要你的服务器中的任何一个环节存在明文（或者是未加盐 hash ）的密码，到时候泄露了都会严重影响用户……

[pabupa]

@listnodeptr 那如果你这么做，那在服务端怎么验证用户的密码强度？

[listnodeptr]

@pabupa
前端校验密码强度即可，如果有黑客强行修改请求设置自己弱密码，那他要是被盗我们真的不管了，不过 99.9999%的用户都不会绕过前端限制为了设置弱密码，所以考虑风险可控，已经足够了

以及我们真的能够在服务端验证用户的密码强度（词典），但始终不会搞，为了黑客硬改请求设置弱密码然后被盗这个场景，去让研发加一堆功能是通不过需求评审的。。。