开发APP时：在Firebase中存储用户密码是否合理？是否有必要？

嘿，这个问题问得特别实在——很多刚用Firebase Auth搭建用户系统的开发者都会陷入这个困惑，我来给你拆解清楚：

1. 存储用户密码绝对不是合理选择 #

首先明确说结论：不要自己存储用户的明文密码，甚至加密后的密码也完全没必要，原因有这几点：

• Firebase Auth本身已经帮你做了密码的安全存储：它会用bcrypt这种高强度哈希算法对用户密码进行处理后存储，而且这个过程完全在Firebase的服务器端完成，你根本接触不到明文密码，也不需要自己重复造轮子。
• 存储密码会带来极大的安全风险：如果你的数据库被攻破，用户的密码（哪怕是加密过的）一旦泄露，会导致用户在其他平台的账号也面临被盗风险，这会严重损害你的APP信誉，甚至可能引发合规问题（比如违反GDPR、CCPA等隐私法规）。
• Firebase的登录流程不需要你持有密码：用户登录时，Firebase会直接验证用户输入的密码和它存储的哈希值是否匹配，返回给你的是安全的身份凭证（ID Token、Access Token），你只需要用这些凭证来处理后续的用户授权逻辑就够了。

2. 哪些场景可能看似需要密码？（附替代方案） #

你可能担心某些功能需要用到用户密码，但实际上几乎所有场景都可以通过Firebase提供的能力解决，不需要自己存储密码：

• 修改密码：如果用户当前处于登录状态，你可以调用Firebase Auth的updatePassword()方法，直接让用户输入新密码即可完成修改；如果用户未登录或忘记密码，走Firebase的密码重置流程（发送验证邮件/短信），用户通过邮件链接就能重置密码，全程不需要你介入存储密码。
• 敏感操作二次验证：比如用户要修改手机号、删除账号这类敏感操作，你可以用reauthenticateWithCredential()方法，让用户输入当前密码，Firebase会帮你验证身份的合法性，验证通过后再执行操作，你依然不需要存储密码。
• 第三方服务集成：如果需要对接某些需要密码登录的老系统，优先考虑用Firebase的自定义Token或者OAuth授权来实现，而不是把用户密码同步到第三方系统。
• 离线登录：Firebase Auth支持持久化会话，用户登录一次后，只要APP没有被卸载或用户主动退出，下次打开APP会自动恢复登录状态，不需要用户再次输入密码，也不需要你存储密码。

总结 #

完全没必要自己存储用户密码，依赖Firebase Auth的原生能力既安全又省心，还能避免不必要的安全和合规风险。如果有特定的功能需求，先去深挖Firebase Auth的官方能力，几乎都有现成的解决方案。

内容的提问来源于stack exchange，提问作者Yunus Kulyyev