CLMan

用过第一代 surface pro ，后来当泡面盖子了，对我个人而言没啥用。触控笔对于写程序的用处不大，其实际体验对于使用者的手写能力要求较高（比如专业绘画等），对个人而言不如键盘打字。

个人还是习惯传统笔记本，追求键盘手感。

不喜欢就放弃呗，又不是非学不可。我就尝试过 1 个月，后面就放弃了。

blake 部分原文指的应该是对用户明文进行 hash ，而你所指的是对派生密码进行 hash ，所以强度来讲确实没什么问题。

火狐的办法确实巧妙，因为它是拿用户明文生成的加密密钥，自然是不能上传明文密码，所以最好在客户端使用 KDF 。

@chenjia404 我懂你的意思了，因为 hash 函数的特点，1:N 这种对应关系，其中 N-1 个是无效值，即碰撞就是白费力气，那你的方案确实有趣。当然由于没有知识背景，我无法判断这种说法是否正确。

自从加盐哈希流行以后，安全界为啥还要建议使用 Bcrypt 、argon2 这些密码存储专用的哈希算法呢，无非是担心现有及以后的硬件暴力破解通用哈希算法太快。至于彩虹表，已经是上个过时版本了。

而你认为设计很好的点“ auth_hash 与 user 并非一一对应”，反而是最大的漏洞，因为它们其实是 N:1 的关系（ N 指 auth_hash 表的大小），意味着暴力破解时，可以碰撞的哈希值有 N 个。“这个表数据越多越好”，意味着破解的难度越低。

很多人以为，密码存储哈希值是避免用户的明文密码泄露，其实不然，是避免应用的明文密码泄露。如果是前者，那客户端密码 hash 早就流行开来了，还不至于成为开发者之间的争论点。对于后者，客户端密码 hash 毫无作用。

@liuidetmks 补充 @，内容见上一楼。

你这错得有点离谱，密码存储引入 hash 的历史原因有两个：

- 避免数据泄露，导致攻击者获得本应用的所有账户和明文密码
- 避免被拿去撞库

第一个是重中之重，影响了公司的生死存亡。第二个只能说是附带的，毕竟自己活着才最重要。

因为第一个原因，所以密码存储才经历了通用哈希算法、通用哈希算法+盐、标准密码哈希算法的技术演进。

而客户端 hash ，仅有的作用就是避免第二个原因，尚且属于程序员群体的争论点，并非最佳实践，大部分互联网公司都没有这么做。

现在你为了一点性能，将标准密码哈希算法丢到客户端，而服务端居然使用上古的通用哈希算法解决方案，连盐都舍不得加，不是捡了芝麻丢了西瓜。

事实上，你只要阅读一下你所推崇的 blake2 的官网，就会看到它根本不推荐将 blake2 用作密码存储：“Q: So I shouldn't use BLAKE2 for hashing user passwords?”，而是建议使用标准密码哈希算法。

你说的文件作为密码（或者说种子），KeePass 很早就支持用文件(Key File)了。

你如果是说文件、MD5 、base64/md5/sha256/自己的加密方案都属于生成主密码的前置步骤，那你加入的前置步骤越多，遗忘的概率越大。

“加密的方案只有自己知道”，从学院的角度来讲这会降低安全性，从现实的角度来讲，军用加密算法是非公开的、魔改的。但要实现类似后者的效果，你得有较深的密码学背景，不然就是前者描述的那类人。

很多之前不错的 PE 被收购了，以至于添加了毒。

长期没有接触一些垂直领域，避坑的方法是去相关的专业渠道询问，而不是自己百度一个然后闷头使用。

操作系统相关的专业渠道有远景论坛，稍微搜一下就不至于遇到类似的问题。