Jirajine

@BeautifulSoap 是的，当你提交姓名/住址/银行卡号等个人信息给某个网站的时候，你应该知道你的信息会被任何包括员工在内有权限的人，以任意方式访问/传输/存储/使用/共享，并且你全都无法验证。
这就是为什么要在前端对密码加盐 hash ，使服务端对密码原文保持 zero knowledge 的原因。

@BeautifulSoap 有没有一种可能，我只是一个负责中间件/负载均衡或者其他什么根本不需要接触数据库的组件的开发，我发现某个组件有 bug ，于是就加了几条 log 把部分请求打到日志里。回头我把这些日志收集清洗一下，我就掌握了大量用户的密码了。

或者你认为任何公司的任何员工都做不到/不会做这样的事情？

有没有一种可能，那一万种变相搞到你明文密码的方式，其实都是一种：以后端能够得知原文的方式传输密码。

你如果要只有目的地址为 10.10.10.10 的流量转发给 10.10.10.20 ，那你可以在写规则的时候匹配目的地址。网卡和 ip 没什么关系，从 eth0 进来的目的地址为 10.10.10.10 的包也会被接受，但匹配不到你的规则。

如果你的需求是由 B 向 C 发起请求但是要经过 A ，那你直接在 B 添加静态路由，ip route add <dest_C> via <ip_of_A>，然后在 A 上配置规则决定谁能发给谁。

@FTLIKON
@tsanie
@BeautifulSoap
是的，后端能够得知密码原文是合理的需求，前端加盐 hash 都是逆天。因为这样我可以在哪天倒闭跑路之后把用户的用户名和密码 dump 出来卖给黑客拿去撞库。哦，如果哪个用户跟我 dispute ，我可以直接拿他的用户名密码去其他网站登陆他的帐号给他开盒。

或者你相信任何人都不会做这样的事情？

> 为什么密码要明文传输？
因为太多人认为密码明文传输不是问题。如果你不为这些人开发的服务使用密码管理器生成全随机的专用密码，那你就是受害者。

@AoEiuV020JP 你理解错了，bl 锁是让设备只能运行具有可信签名的系统镜像，有些设备只信任厂商的签名，而另一些设备允许信任用户导入的签名。

@kuanat 是的，kotlin 只能用 jb 自家的 ide 是最大的缺点，被迫用多个 IDE ，每个都有不同的配置/插件/快捷键是很糟糕的体验。

@kuanat kotlin 就别想 LSP 了，jb 为了卖自家的 IDE 不可能提供支持。