别再纠结前端要不要提交明文口令，浏览器已经内置非常好的方案

[iqoo]

这个十年前就有结论的问题每隔一段时间都会有人讨论。结论是不管什么环境，前端提交 hash 后的口令总是好的，防的不是中途的嗅探者，而是脱库后的破解者。前端 hash 越耗时，脱库后跑字典越慢。

至于前端 hash 也不用自己捣鼓 js/wasm 这些，主流浏览器早已内置 PBKDF2 算法，较新的 CPU 都有相应的硬件加速，比自己实现可以快很多倍。

演示：

const username = new TextEncoder().encode('alice')
const password = new TextEncoder().encode('hello1234')

// 重复 1000 万次 SHA256
const pbkdfOpts = {
  name: 'PBKDF2',
  hash: 'SHA-256',
  salt: username,
  iterations: 1e7,
}

async function pbkdf2(pwd, opts, bits) {
  const baseKey = await crypto.subtle.importKey('raw', pwd, 'PBKDF2', false, ['deriveBits'])
  const buf = await crypto.subtle.deriveBits(opts, baseKey, bits)
  return new Uint8Array(buf)
}

const dk = await pbkdf2(password, pbkdfOpts, 256)

// 注册/登录提交 dk 即可，无需提交 password
console.log(dk)

[danhahaha]

前后端纠结于各种算法的安全性，用户依旧 123456 走天下

[dode]

@gamexg
CDN 理论上可以直接修改你的网站内全部东西，比如给密码输入框增加一个密码收集函数

@iqoo
你这前端有一个通用接口查询用户难度，岂不是泄漏用户名称，导致用户 ID 被暴力爬取，脱库

[gamexg]

@Chad0000 #60 我回复错了, 回复的 @rxmt .
不是用 hash ,而是直接自己再实现个公钥加密,来防止 CDN 处有问题造成泄露密码.

国内不知道,我是知道国外一些机房管理混乱程度.
以前公司的租的物理机被入侵了,
排查日志发现,被人用机房的账号登录了 ipmi ,重启服务器添加账号实现的入侵.
还是比较大的机房,全球都有机房的....

[gamexg]

@dode #62 添加密码手机函数被发现的风险就大得多了.
我是觉得非针对单个网站,广谱的密码收集工具还是监听方式实现更不容易被发现.

当然真的被专门针对的话那就只能说认了,
即使将登陆相关的改为独立子域名不经过 CDN,但是 CDN 还是能够利用经过的域名获得 cookie .
甚至将登录域名改为经过 CDN 的域名.

[knva]

纠结这个不如让用户来个 16 位以上大小写特殊符号密码

[forty]

1. 要防 CDN ，那就自己再来一层公钥加密。
2. 要兼顾多版本客户端：
2.1 在客户端提交请求时，附带客户端版本号，以便后端识别后区别采用新旧算法
2.2 或在新旧客户端都保持长期固定不变的算法。

至于说要后端保存每种不同 hash 值的，完全不需要。

[Chad0000]

@forty #66
“ 至于说要后端保存每种不同 hash 值的，完全不需要”

要不你再仔细想想？当然如果你说只限 web 当我没说。

[DesnLee]

没看到有人讨论 bcrypt 呢

[sampeng]

我一直奇怪这有啥好讨论的。。。。

[forty]

@Chad0000 web 也是个客户端，跟别的客户端没有本质区别

[liuzhaowei55]

pbkdf2 在动态 salt 的情况下才有意义吧

[zhzbql]

花里胡哨的不如强制密码长度增加 2 个字符

[supuwoerc]

我用的 bcrypt...

[fionasit007]

说得好，实操还是 md5 一把梭

[forty]

@zhzbql 直接来短信验证码，或 2FA ，省事了。

[Chad0000]

@forty #70
在是否能及时更新（算法）这个方面有很大区别。

[forty]

@Chad0000 当然能及时更新，前面已经有兄弟说了，就是支持多种算法的。

[Chad0000]

@forty
完全换另外一个算法的话，你就需要提前部署那个算法。否则 app 来不及适配，尤其是紧急安全事件，你得有足够窗口期提前安排。还是那句，搞这么复杂到底提升了多少安全性。

[forty]

@Chad0000 你说的“紧急安全事件”是指某个哈希算法不安全了吗？这种不会紧急。一般紧急都是数据库或某些算法泄露吧，这种就换后端算法啊。 客户端算法就保持不变，固定一套基本的哈希就够了，可变部分由服务端来提供。

你说的“搞这么复杂”不知道所指是哪个方案，是指 OP 的那个吗？我其实并不认同 OP 方案。

不复杂，也可以实现我说的：

[ [
1. 要防 CDN ，那就自己再来一层公钥加密。
2. 要兼顾多版本客户端：
-- 2.1 在客户端提交请求时，附带客户端版本号，以便后端识别后区别采用新旧算法
-- 2.2 或在新旧客户端都保持长期固定不变的哈希算法。(算法不变，但是参数会变，结果会变)

至于说要后端保存每种不同 hash 值的，完全不需要。
] ]

[expy]

前端 hash 后，数据库是直接存前端的 hash ，还是用 argon2 之类专用算法再 hash 一次？