React Native应用存储用户凭证的安全疑问及方案咨询

问题1：已开启越狱防护的情况下，使用Keychain存储凭证是否仍存在问题？ #

• 仍有不可忽视的风险：
  • 越狱防护可被绕过：资深攻击者能通过动态调试、hook防护代码等方式突破检测，设备一旦越狱，Keychain的访问限制会被解除，凭证可能被直接提取。
  • 系统级漏洞威胁：旧版本iOS/Android可能存在Keychain/Keystore的零日漏洞，攻击者无需越狱就能利用漏洞读取存储内容。
  • 应用自身漏洞隐患：如果应用存在内存泄露、逻辑漏洞，攻击者可能在防护触发前就获取到凭证，不用依赖越狱设备。

问题2：在无法使用OAuth类刷新令牌/授权码许可时，存储凭证是否为移动开发的标准流程？ #

• 这是行业内的常见做法，但属于次优方案：
  • 当身份提供商不支持OAuth/OpenID时，存储用户凭证（如用户名+密码、长期令牌）是实现自动刷新的主要方式，但风险远高于OAuth机制——凭证一旦泄露，攻击者可长期操控用户账户。
  • 标准流程优先推荐OAuth的刷新令牌模式，因为刷新令牌权限受限、可随时撤销，而存储原始凭证的风险不可控。

问题3：有无其他可采用的替代方案？ #

• 可以尝试以下几种思路：
  • 向身份提供商申请权限受限的长期专用令牌：用这类令牌替代原始用户凭证，即使泄露，影响范围更小，且提供商可随时吊销。
  • 实现短令牌+服务器端会话绑定：应用每次请求时，用短令牌结合设备唯一标识（如iOS的IDFA、Android的AAID，需注意隐私合规）向服务器验证，服务器端维护会话状态，令牌过期后通过设备标识重新获取，无需存储用户凭证。
  • 采用生物识别绑定的一次性令牌：每次需要刷新时触发生物识别（Touch ID/Face ID、指纹），应用向身份提供商请求临时令牌用于刷新，不存储任何长期凭证，但会牺牲部分用户体验（每次刷新需验证）。

问题4：若按建议加密凭证，加密密钥的安全存储位置有哪些（存入Keychain会失去意义）？ #

• 可考虑这些安全存储方式：
  • Android Keystore 生成并托管密钥：直接在Keystore中生成对称/非对称密钥，密钥永远不会离开Keystore，仅能通过应用上下文调用使用，即使设备Root，攻击者也无法导出密钥本身，只能尝试通过应用进程调用加密/解密操作。
  • iOS Secure Enclave：将加密密钥存储在独立于主处理器的硬件安全模块中，密钥无法被导出，仅能通过生物识别或设备密码授权后使用，安全性比Keychain更高。
  • 基于设备硬件信息派生密钥：利用设备唯一的硬件标识（如CPU序列号、主板ID，需注意平台获取限制和合规性）结合用户PIN/生物识别，派生加密密钥。但硬件标识可能被读取，简单PIN也易被破解，需谨慎使用。
  • 运行时生成密钥，不持久化存储：每次应用启动时，通过用户输入的PIN/生物识别生成密钥，加密凭证后存储，应用退出后密钥销毁。但这种方式无法实现完全自动刷新，每次启动或刷新都需要用户验证。

内容的提问来源于stack exchange，提问作者Ishan Hettiarachchi