## 背景 #2758 的策略 3:老系统迁移时希望用户**沿用原密码**,导入行携带预哈希值而非明文。#2766(PR #2771)明确将其排除在 V2 之外——当前 `/admin/import-users` 会忽略导入行的 password 列。 ## 现状可依托的点 - better-auth 支持自定义 `emailAndPassword.password.hash/verify`;`resolvePasswordHasher()`(`auth-manager.ts`)已有注入雏形(目前仅 WebContainer 环境注入 noble-scrypt,与原生 scrypt 互验)。 ## 诉求 1. **哈希格式约定**:导入行声明算法与参数,如 `{algo}${params}${salt}${hash}`(bcrypt/pbkdf2/sha256+salt/旧 scrypt 参数等),入库带算法前缀以便混存区分。 2. **verify 端多算法 dispatch**:登录验证时按前缀选择验证器;未带前缀的走 better-auth 原生 scrypt(存量不受影响)。 3. **首登 rehash**:外部算法验证成功后,用原生 scrypt 重哈希替换,存量逐步收敛到单一算法。 4. **导入接线**:`/admin/import-users` 增加 `passwordPolicy: 'prehashed'`,行携带 `password_hash` 列;红线不变——哈希值同样**禁止进日志/审计/Job 结果**(哈希也是凭据材料)。 5. 支持的算法集合从最小可用开始(建议 bcrypt + pbkdf2),按迁移需求扩。 ## 风险 - 弱哈希(如无盐 MD5/SHA1)应明确拒绝导入而非兼容。 - 自定义 hasher 是全局配置,需确认对 haveIBeenPwned、密码历史(`previous_password_hashes`)等既有机制的兼容性。 ## 相关 - #2758(原始需求,策略 3)、#2766 / PR #2771(导入端点,本 issue 在其上扩展)
Activity