屎山是不可避的，要不然也不会发明 go 了。

@liuhan907 浪费？你去看看那些泄露检测的网站，还有不少商业密码管理器自带的泄露检测功能，要是有哪个上传明文密码，赶紧去 hn 发帖把它批倒批臭。
再者说这种情况也不需要加盐，常规做法是 hash 后取一小段发送到检测接口，如果有命中则把命中项取回前端再比对。

@GeruzoniAnsasu 你扯一堆晦涩的论证并不能掩盖结论的错误。前端 hash 的作用我上面已经说了很多遍了，“假如你密码足够随机”你是不是忘了还有其他用户的密码不够随机？
你没耐心去看一眼我上面发的 bitwarden 的白皮书的话，思考这个问题：
如果前端不发送 hash 后的结果到后端，我如何证明自己无法解密用户的数据？

@zpf124 我见过的所有弱密码判断，都是检测字符集范围，就是判断是否有符号、数字、大小写字母这些，没见过什么穷举。
至于已泄露密码判断，发送 hash 后的结果到检测接口即可。

@GeruzoniAnsasu 你扯的太偏了。我上面说了多少遍，加盐 hash ，每个网站每个用户的盐都不一样，哪来的“明文撞出来”、“同样的密文”。要是每个用户都为不同网站使用不同随机密码就没那么多事了，但事实上不是这样，他们的密码常常简单、一样、包含其他隐私信息，你说该不该加盐 hash ？
从用户的角度来说，发送明文（或可还原出明文的密文）密码是无法证明服务商没有存明文的。所以服务商只要注重安全，保持对用户明文密码的 zero knowledge 是至关重要的。access token 和明文密码的区别，不用我再赘述。
至于密码管理器怎么和撞库联系起来我暂且蒙古，用了密码管理器你只需要一个足够复杂的主密码（或配合密钥及 yubikey 等介质），该密码从来不在任何其他地方使用，也不会以任何形式传输和存储。你的个人设备根本从无法公网访问，怎么会被撞库？就算你本人是高价值人士，也有 veracrypt 这种提供 plausible deniability 的工具。使用密码管理器可以所有帐户全随机强密码，任何形式的撞库的影响不到你。按你说的那样用一样或有规律的密码，如果对方明文存储，可以以此识别你的身份。

@liuhan907 前端可以自己检查强弱，至于泄露更不用发送明文。

@zpf124 前端 hash 和后端 hash 是互不影响、完全无关且相互独立的两件事。前者是为了避免撞库和保持 zero knowledge ，无论后端是否 hash 。后者是为了避免脱裤后登录，无论前端是否 hash 。
至于公钥加密同上，后端依旧能得到用户的明文密码。
前端 hash 唯一的缺点就是倒闭了之后不能卖用户的秘密库。

驻英国大使也想知道

@zpf124 你再仔细想想。拿到后端 hash 后的结果不等于拿到前端 hash 后的结果。
前端 hash 和后端 hash 是两个截然不同的安全层。前者的意义在于让后端不能接触到用户的明文密码，对用户的密码保持 zore knowledge 。而后者是阻止本站被脱裤后攻击者登录本站用户的账号。我上面主要强调第一点因为我觉得第一点更重要，因为本网站被拖总是有感知的，有感知就有办法补救。其他网站撞库才是最大的威胁。
而你们说的好像一但做了第一点就不能再做第二点了，事实上做不做第二点是另一个问题，与第一点没什么关系。
具体的例子可以去看看 bitwarden 的白皮书。

@keyfunc 我倒不是觉得审计造假。事实上我相信目前的审计可以确保不会出现大范围的中间人攻击，如果国家有这个需要可以强制安装或让流氓软件偷偷安装自己的私有 CA 证书。我担心的是在完全可控的网络环境下针对特定目标的攻击。 至于搬服务器没啥意义，这里指的肯定是不受控制的目标。

Google 开定位小心 IP 送中。

我觉得主要是前后端分离的流行，传统 MVC 越来越少了，后端 Sinatra 这样的纯 API 比 rails 全套更常用，而纯 API Ruby 也没啥优势。
@agagega Ruby 太灵活、太自由了，实在不适合静态检查，试过 Stripe 搞的静态类型检查器，体验只能说一般。加静态检查最成功的是 typescript ，Python 也勉强可以。

@tlmn --color=auto 的意思是让 ls 命令自动检测输出是否为 tty ，是则带颜色，不是则不带（并且格式也不一样）。
而上面的劫持是强制让程序认为输出目标为 tty 。
常规来说 ls 默认就是--color=auto 的，但也可能你调用的 ls 不是 /usr/bin/ls ，而是 shell 覆盖定义的函数或 alias ，从而自带了一些参数可能改变默认行为。
所以这里显式指定，一方面避免可能的干扰，另一方面更清晰地表达出这个劫持的作用：即欺骗程序对自动颜色输出的检测。

@GuuJiang hash 之后还可以再次 hash ，不过我说的重点不是这个，而是将原始明文密码发送到后端的不可靠性。
脱裤后泄露最大的危害是撞库，某个网站自己被脱了他肯定有补救措施，比如强制两步验证、暂停登录等。但其他网站就不行了。只要加盐 hash 至少一次就可以确保 A 站脱的库无法威胁到 A 站以外的其他网站的用户帐户，这才是最关键的。
另外如果前端将明文密码发送到后端，那这个服务就是不可信的，你没法验证他到底有没有存储明文。除了内鬼泄露、脱裤被拿去撞库以外，很多不使用密码管理器的用户的明文密码中同时 encode 了如生日、名字拼音等隐私信息，可以在社工的时候提供相当的参考。

Python 应该是非程序员用户最多的语言了。

@opentrade egui 还是挺完善的，嵌入到 gl/vulkan/wgpu/glfw 等上下文中非常方便。
追求性能的话考虑一下分窗口，主界面、控制界面逻辑复杂、多交互，用 webview 或 flutter 写。渲染窗口注重高性能，控件简单，用原生的图形 API 配合 egui 少量组件。可以参考一下那些游戏串流的工具，嵌入到其他 GUI 库里性能可能很难达到要求。

@ysc3839 你也说了是国产。我指的是在法治国家具有业务的国际品牌。