android - Firebase Authentication Android SDK 如何保留刷新 token ？

Question

我正在阅读文档，但我找不到 SDK 如何在设备上保留刷新 token ，以便在应用程序被终止时能够保持用户身份验证。
我想知道的是:

存储刷新 token 的位置

如何保护刷新 token 以防止恶意行为者窃取它

有人对此有任何见解吗？

Answer 1

在创建了一个集成 Firebase Auth 的小型演示应用程序并对其进行检查后，我想我找到了我想要的东西:

刷新 token 存储在哪里？ 在 SharedPreferences

如何？ 纯文本

细节:
Firebase 身份验证使用 SharedPreferences缓存与经过身份验证的 Firebase 用户相关的所有信息。
存储在 SharedPreferences 中的数据对象被写入应用程序内部存储目录中的纯文本 XML 文件。该文件可以在以下位置找到:

/data/data/{app_package_name}/shared_prefs/com.google.firebase.auth.api.Store.{hash}.xml

该文件包含两个键值对，它们都包含刷新 token :

com.google.firebase.auth.FIREBASE_USER :

{
  "cachedTokenState": "{\"refresh_token\":\"AIwUa...\",\"expires_in\":3600,\"token_type\":\"Bearer\",\"issued_at\":1651836746042}",
  "applicationName": "[DEFAULT]",
  "type": "com.google.firebase.auth.internal.DefaultFirebaseUser",
  "userInfos": [
    "{\"userId\":\"sDa2XJk...\",\"providerId\":\"firebase\",\"email\":\"user@email.com\",\"isEmailVerified\":false}",
    "{\"userId\":\"user@email.com\",\"providerId\":\"password\",\"email\":\"user@email.com\",\"isEmailVerified\":false}"
  ],
  "anonymous": false,
  "version": "2",
  "userMetadata": {
    "lastSignInTimestamp": 1651836746972,
    "creationTimestamp": 1651579404681
  }
}

com.google.firebase.auth.GET_TOKEN_RESPONSE.{hash} :

{
  "refresh_token": "AIwUa...",
  "access_token": "eyJhb...",
  "expires_in": 3600,
  "token_type": "Bearer",
  "issued_at": 1651836746042
}

安全隐患:
该应用程序的 internal storage SharedPreferences 所在目录文件存储在非 root 设备中的其他应用程序无法访问，并且在 Android 10 或更高版本的设备中已加密(因为基于文件的加密现在是强制性的)。
安卓的 Auto-Backup自动将应用程序的内部存储目录备份到运行 Android 6 或更高版本的设备上的 Google Drive。备份在运行 Android 9 或更高版本的设备上使用设备的 PIN 码、图案或密码进行端到端加密。
基于上述情况，刷新 token 可能(至少)在以下情况下受到损害:

在 root 设备中，具有 root 访问权限的应用程序可以读取 SharedPreferences存储刷新 token 的 XML 文件。

在 Android < 10 且未启用全盘或基于文件的加密的没有开启Root的设备中，对设备具有物理访问权限的恶意行为者可以挂载磁盘并读取刷新 token 。

使用 adb backup 创建备份时, 加密备份文件是可选的。如果备份未加密并且恶意行为者获得了对备份文件的访问权限，他可以从中提取刷新 token 。

在 Android ≥ 6 且 < 9 且为应用启用自动备份的没有开启Root的设备中，存储在 Google Drive 中的备份文件未进行端到端加密。因此，获得您 Google 帐户访问权限的恶意行为者可以访问备份文件，从而访问刷新 token 。

潜在的缓解措施:

添加根检测以警告用户其风险(或假设拥有根电话的用户已经知道它们)。

如果未启用，建议用户启用加密。

排除 Firebase 身份验证 SharedPreferences从备份文件。

但是如果需要完全遵守 OWASP MSTG-STORAGE-1 rule :

System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys.

那么您唯一的选择是使用 Firebase Authentication REST API 而不是使用他们的 SDK，并使用适当的加密存储(如 EncryptedSharedPreferences)自己保存刷新 token 。 .
否则，您可以考虑一些默认情况下在其 SDK 中支持加密的替代提供商，例如:

Auth0

Okta

该测试是针对 Firebase Auth v21.0.3 执行的，这是撰写本文时的最新版本。

更新:
我找到了 this statement Firebase 团队关于他们的方法:

As for the named SharedPreferences file, com.google.firebase.auth.api.Store.{code}.xml, that is, indeed, where we persist user state. When the application goes into the background or is closed, the currently logged-in user needs to be stored somewhere, and SharedPreferences is a safe place to do so - it has private filesystem permissions, meaning that only that application (or a process with root permissions) can read it. As such, encryption isn't necessary. In general, Firebase only makes security guarantees about unrooted, non-userdebug devices; the security properties of rooted or userdebug devices are significantly degraded in ways that we cannot properly account for.

Still, the question remains, why don't we encrypt things in storage? The answer is pretty simple: it provides no additional security (other than security-by-obscurity) and has both a performance and complexity penalty. For example, a root user can also access the Android Keystore as the target application, meaning that they can still read the SharedPreferences, they just have to read and use the appropriate key first.