@zhenjiachen
对比方案可以参考 112 楼的设计。其实就是很简单的 nonce+hash 的嵌套。

其实只要换个角度就好理解了：你把密码第一次做了 hash 之后的结果当明文，然后该咋办还是咋办。

bcrypt 说到底只是一个样板方案，只要能达到效果就行，不是说非得严格死板一条条按它那个来的。

@zhenjiachen

你前端都使用 bcrypt 了，还多此一举把明文传给后端干嘛？当然是直接把 nonce 和 hash 传给后端啊。

主要是你的思路实在太奇怪了，从头到尾除了你就没人说 aes ，就算要加密口令也不可能脱离 tls 单独用 aes 。不赞同用 aes 听起来就像不赞同裸 http 明文传递密码一样，不赞同了个寂寞。

@zhenjiachen 不持久化存就根本不需要 AES 加密啊。即使要加密也可以用非对称加密，这样就没有逆向破解的问题。

而且前端可以直接做 nonce+hash 的 bcrypt——至于原因，前面某楼已经说了，哈希跟加密相比，最大的区别是避免后端得知密码明文。

@zhenjiachen 又不在前端持久化存密码，你要加密干嘛？

bcrypt 跟传输密码的哈希又不矛盾

@HojiOShi Java 给我的感觉正好相反：除了你开发的目标环境必须用 Java ，没有任何使用 Java 写东西的理由。

而且不是现在如此，在十年前可能就已经是这样了……

@FTLIKON 因为证书误用导致的 https 破解其实并不罕见。

其实就算证书没误用，如果 ciphersuite 配的不对，也完全有可能被破解（不过说实话现实中没见过类似的攻击案例，只在 PoC 中见过）

其实关于 https 传输明文密码这个问题，答案是很确定的。

它肯定没有传输加盐哈希安全，但对于 99%的情况足够安全。

当然，1%并不是一个很低的概率，所以现实中我们也可以看到因为明文传输、存储密码导致的大规模安全问题已经发生很多次了。

对新手来说，Mac 不会用，Windows 会用，Windows 胜。

对刚入门的人来说，Mac 能避免一些配环境的 corner case ，相比 linux 又更易用一些。Mac 胜。

对老手来说，没有我配不好的环境，没有我编译不了的库。啥平台都一样。

@carpeDiemJll 很多二三线城市的房并没有那么便宜。稍微像点样子的也得两三百万了。

既然 AI 写的代码不好，你又干嘛不写更好的代码呢？这不就是为什么别人用了 copilot 没废，而你废了么。

如果就手机一个平台的话，说真的不如开个云同步服务。比如 iCloud 。

价格比 NAS 便宜得多，2 个 G 的容量也绰绰有余

@ExplodingFKL 要分清楚产品设计和底层实现的差别。

island 和手机分身之类的功能，固然都是用的 AOSP 账户系统做底层支持，但体验却天差地别……对用户来说，实际有感知的是端到脸上的产品，而不是一组底层 API 。

IV 为 0 的 CBC 确实不够安全，但你要说能从密文这样推理出明文，那我只能说绝无可能。

这些在我看来甚至都不是正常消费，而是必要消费。

结合一下咯，用 inotify 检测到删除文件，就去 auditctl 中拉取删除信息。想展示成什么样自己拼接一下就好。

代码提示是看头文件能不能找到，link 能不能通过是看静态或者动态库能不能找到，这俩是两个路径，确实没什么必然联系。

可以考虑用 vcpkg 装，稍微友好一点

“实验室”一般是脱离一线业务，更专注于科研的模式。放在安全领域，很多时候就是以挖洞、发论文、CTF 之类的东西做主要内容。

其它厂商内部也有类似小团队的，只是不一定叫这个名字

@dhb233 不天天去迭代新需求的话，其实稳定性和优化挺容易做的，其实大家都能做到

软件体验的本质是产品和 UX 设计。本质上跟程序员没什么关系，而是产品经理、设计师们的审美水平、用心程度决定的。