iseki

那起码要为商家再次寄出准备好新的虚拟号吧🥺😣

@iseki 从认证这个业务逻辑上当然不需要获取原始口令，也不该这么做

@lesismal 按这种讲法就没什么可讨论的了。一切当然是可以改的，就算是碰到必须获取原始口令的设施你也可以说改造旧设施，那还有什么可说的呢。

不是，举个例子 LDAP 登录，这是很常见的需求。业务逻辑是尝试使用搜索到的 DN 和用户提供的口令 Bind ，Bind 成功即为认证成功，这就必须把用户输入的原始口令发送过去。

@lesismal 明文向后端传输虽然不好，但有时这是工程上成本刚好可以接受的方式。一来我刚才说了，很难设计一个有足够收益的非明文传输方案，二来就是有时候后端的某些设施只能接受明文。

@lesismal 工程上多一行代码也是有成本的，不能做不划算的事。我可以接受口令在妥善的哈希后传递给后端，但我不能接受把口令 base64 之后传给后端，base64 在这里就是一个收益近乎为 0 的操作（即使它的成本很低），总结下来就是一句话，不做不必要的事。
避免向后端传递原始口令是有必要的（中间设施，日志系统，甚至后端服务本身都可以有缺陷和风险），但必须弄清该怎么做，而不是简单变换一下弄得一眼看不出来就完了。

@lesismal 这文本复制的可真有意思，也怪我，下次用 Kotlin 风格的方式表达。
这个接口的风格是工程要求，你也可以看一下我在这条文本之后的跟帖，大概有这么个现实问题是不太好解决的，你可以给出你的解决方案讨论一下。

也许可以在前端对口令完成一次困难哈希，但难度和风险在于这个哈希的算法和参数从此固定不能更改，也意味着日后所有的「客户端」都要能自主完成这套逻辑。

此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。