Supabase与Firebase用户迁移中的密码哈希兼容性问题解析

背景与问题本质

在身份认证系统迁移场景中，Supabase与Firebase的密码存储机制存在根本性差异。Firebase默认采用SCRYPT算法进行密码哈希，而Supabase则使用bcrypt作为默认哈希算法。这种算法差异导致直接迁移的用户无法通过密码认证，具体表现为"invalid_grant"错误。

技术细节对比

1. Firebase密码存储结构

   • 字段名：passwordHash
   • 算法：SCRYPT
   • 特点：包含独立存储的哈希参数（rounds/mem_cost/base64等）
   • 示例格式：{"hash":"...","salt":"...","signer_key":"...","salt_separator":"...","rounds":8,"mem_cost":14}

2. Supabase密码存储结构

   • 字段名：encrypted_password
   • 算法：bcrypt
   • 特点：遵循PHC字符串格式（$2a$10$...）
   • 示例格式：$2a$10$d31Fd//DLU.28P2H3.ywpOqkfrBODA74IlmuNtU3LbJPm/1hhYGhy

解决方案演进

开发团队最初考虑采用类似argon2id的标准化处理方案，但发现SCRYPT的元数据存储方式存在特殊性。经过技术评估后，确定了以下实施路径：

1. 标准化哈希格式

   • 定义统一的SCRYPT参数编码规范
   • 确保哈希值与参数可被Supabase认证流程解析

2. 向后兼容设计

   • 保留现有bcrypt支持
   • 新增SCRYPT识别逻辑
   • 实现多算法认证路由

对开发者的建议

1. 迁移前检查Firebase用户的passwordHash字段完整性
2. 等待官方支持SCRYPT的版本发布后再执行批量迁移
3. 测试阶段建议同时保留两种认证系统并行运行

技术展望

该问题的解决将为多云身份认证系统迁移建立新的范式，未来可能扩展支持：

• PBKDF2等其他常用哈希算法
• 自定义哈希参数的配置能力
• 自动化迁移工具链的开发

当前解决方案已进入代码审查阶段，预计将在近期版本中发布。建议开发者关注官方更新日志获取最新进展。