LnTrx

对于非专业用户，手机号+验证码还是最方便，国内还能顺便落实实名制。毕竟来一句密码忘了/验证器删了/Key 掉了还得用其他方法来验证。
对于专业用户，Yubikey 这种推广的麻烦点还是在于成本，基于设备本身安全芯片的 Passkey 可能会应用更广。

@ShuWei 增加复杂度有时也会降低安全

@maggch97 关键在于要说明对安全的提升有多大。如果只有十分细微的提升，虽然也是好事，但是这样场景数量太庞大，会给工程带来不必要的复杂度。而增加的复杂度又会反过来增加风险。

尝试总结一下

用户端：
恶意软件/人员有很多手段获得密码，很难想象一种只有 HTTPS 内明文才能获得密码的场景。（安全的增益太细微）

中间人：
当前移动端安装根证书很难，PC 端需要权限。如果有本事装上，那同样有很多手段获得密码。
既然是中间人，那自然可以篡改网页，从你手里明文获得密码再加密发给网站，双方都无感知。（只有当中间人坏但又不完全坏时才有意义）

服务端：
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠，到处都是漏洞，单单密码加密意义不大。
无论前端有无加密/散列，服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景，例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究，如果是明文可能会心生歹意。在这种
情况下，加密也许存在一定意义。

关键要讲清楚，前端加密的目的是什么，要防止什么样的攻击/泄露。对于用户侧的攻击，找不要有意义的场景。对于服务侧，因为会有很多环节，加一层防止意外泄露还算有那么点道理。

个人看下来：
对于用户侧，如果恶意软件/人士已经掌握足够权限，那再 HTTPS 内再加密也没意义。关键是要找到一种场景，HTTPS 内再加密能防住、HTTPS 防不住，且这种场景有考虑的价值。我暂时没还想到。
对于服务侧，经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发，通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御，那 HTTPS 内再加密还有点意义，据要结合具体场景分析。就拿 CDN 举例，如果 CDN 是坏人，只加密密码，用户隐私、Token 等信息都是明文，那一样可以窃取信息、拿下账户、伪造信息，那加密的意义也就不是很明显。

搞不好是总部玩 AI 玩崩了