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 被收购了，以至于添加了毒。

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

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

@CLMan

我推测你想表达的是，方案一强调 d,e 是可选参数，方案二强调 d,e 是必选参数。

我推测你想描述的场景是：d,e 可以完全由用户决定（后端只检查值的合理性），或者由后端提供值。
那通常是选择方案一，因为更简单，没必要多两个接口出来，对用户来说使用更加复杂。

你的设计方案，核心接口都是/create ，而且参数列表也是一致的，我没看出来有什么本质区别。

你的表述有些混乱，我帮你理清一下：

- 如果 d,e 是完全由用户决定，那为什么提供/get_d,/get_e ？

- 如果 d,e 由后端生成，用户选择，那提供/get_d,/get_e 是必然选项。

- 如果 d,e 完全由后端生成，那为什么提供/get_d,/get_e ，只需要参数列表 a,b,c 就行了，后端自己调用 get_d,get_e 。

可以参考别人的实现： https://github.com/emirpasic/gods/blob/master/stacks/arraystack/arraystack.go

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#dependencies

有的人习惯自己解决问题，有的人习惯问问题，过于独立或者过于依赖别人其实都不好。

@CodeCodeStudy NaN 是计算机为了满足数学需求搞出来的，在浮点数的标准 IEEE754 里面有规定，现代编程语言差不多都支持这个概念（因为都依赖于底层实现），这怎么能怪到 JS 去。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Invalid_date

Invalid Date 有点类似 null ，算个小坑，要在源头（ new Date()）进行检测（这意味着与其它编程语言并没有太大区别），后续代码并不需要防御性编程。

个人认为比较坑的，是 Array.isArray()这种需要额外记忆成本（因为浏览器跨框架的原因）的东西。

简单来讲，大部分程序都是输入-计算-输出的顺序执行流模式：

- 并发强调：允许逻辑上存在多个执行流同时执行
- 异步强调：执行流的顺序执行模型被打破了，实际的执行过程可能是：输入->提交计算任务->返回，计算的执行是不确定时间的，即与执行流脱钩

类似的问题个人认为是少看点比喻，因为它们与实际代码似是而非，反而容易弄混。

@CLMan 更正下，是我的亲表哥（亲舅舅的儿子），是 2020 年，煤炭的一氧化碳事故，去世的，当时才 28 岁。

并不是劝退楼主，只是刚好有这么一件事，对我触动蛮大的。

我有个表哥，92 年的，他在矿里是负责安全检查的（具体职位我也不清楚，感觉应该不是专门下矿那一批），2021 年的时候，矿里渗水，人没了。

你应该是指前端对明文密码进行 hash ，也就是用 hash 值作为密码，避免后端因为日志等原因导致用户原始密码泄露，从而被拿去撞库。

这里存在几个问题：

- 这种方式，唯一的作用就是密码传输的中间环节泄露后防止撞库其它应用。对用户而言，不同应用使用不同密码是个人信息安全的基本准则。对开发者而言，避免日志记录密码明文是常识。此外，密码明文在 TLS 的中间环节被泄露，而服务器却没有被攻破的场景太过理想。
- 这是一种魔改，不符合已有的密码认证协议，比如 Basic access authentication 。
- 对于多端应用，现有系统改造，需要废弃掉旧的应用版本。

简单来说，有用但没太大用，而且存在兼容性问题，以及升级成本。

美国是现代计算机的发源地，当时的先驱们只考虑了英文字符，也即是 ASCII 。C 语言诞生的时候，还处于计算机的早期发展阶段（大陆同期还在文革），因此当时只考虑到 ASCII （ char 类型的概念及相关标准库）。

后来，C 语言流传到各个国家，对汉字等非英文字符的支持，都是非官方标准，需要修改编译器和标准库实现。主要考虑两点：

- 字符常量的编码，字符串常量被编码为字节存储在库或者可执行文件里面
- printf 等涉及编码的标准库函数

再后来，C 标准更新，以增加对非英文字符的支持，比如：

- C99 支持使用转义字符形式的 Unicode 标识符
- C11 在语言上支持 u,U,u8 前缀表示的 UTF16,UTF32,UTF8 字符串，在标准库 uchar.h 里提供了 Unicode 支持
- C23 支持使用 u8 前缀表示的 UTF-8 单字节字符

------

字符集和字符编码应当是 CS 专业的基础知识（计算机科学概论），ASCII,ISO-8859,GB2312,GBK,Unicode(包括 UCS-2,UCS-4),UTF-8&UTF-16&UTF-32(以及 LE,BE,BOM)是计算机发展史在字符上的一个切面，可以参考阮一峰的博文： https://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

在我第一次尝试学习第二门语言时也会有你一样的想法，也给我带来了许多困扰。我的思路是这样：

1. 掌握编程的常识，《 SICP 》或者说 CS 61A 就是提供这方面的知识，好一点的科班教育在入门阶段基本都会提供类似的课程。

变量、常量、类型、运算符、语句表达式、函数、对象、递归、异常、OOP 、函数式...，要对这些概念的内涵和用途有所理解。

现代的商业编程语言都离不开这些通用的概念，可能会添加新的概念，可能会做语法变更。

2. 掌握 CS 的常识，这对非科班出身的人来说是一个障碍，编程语言里面的很多概念来自于其它的 CS 领域，比如数据结构(hashmap,list)、操作系统（同步、异步、线程），编程语言的书籍由于预设你具有相关领域知识，或者由于语言封装的原因，并不能很好的帮你学习这些概念。

3. 不要去死记硬背语法细节，而是在使用中熟悉语法，信任语法手册、笔记、现代 IDE 、ChatGPT 。语法遗忘是正常的，是否学会一门语言并不是你能否将语法倒背如流，而是你用该语言编写了项目从而给你了信心。

4. 关注 diff ，当你以及有了足够的知识，学习新的编程语言时，只需要带着该语言的设计思想与你学过的语言（同生态位，或者设计上存在渊源）进行比较，区分不同。

@kneo 用户反馈的，好像是 360 和微软。