存储令牌安全是移动应用程序安全的关键。令牌是用户账户、敏感数据和服务的钥匙。如果被破坏,它们可以导致 身份盗窃、金融欺诈和数据泄露保护它们的方法如下:
关键点:
- 使用本机安全存储: 在 iOS Keychain 或 Android Keystore 中存储令牌以获得硬件级别的安全性。
- 在休眠状态下加密令牌: 使用像
EncryptedSharedPreferences(Android) 或CryptoKit(iOS) 等工具进行安全加密。 - 限制令牌暴露: 使用短期令牌和刷新令牌轮换来降低风险。
- 安全通信: 始终使用 HTTPS,并实现证书固定以防止拦截。
- 管理令牌生命周期: 定期过期、刷新和撤销令牌以最小化窃取的损害。
快速比较存储方法:
| 存储方法 | 安全级别 | 易用性 | 最佳用例 |
|---|---|---|---|
| 内存存储 | 高 | 低 | 短会话、高安全性需求 |
| 本地存储 | 低 | 高 | 非敏感数据 |
| 安全Cookie | 高 | 中 | 使用服务器端控制的Web应用 |
| iOS密钥链 | 非常高 | 中 | iOS应用存储敏感令牌 |
| Android密钥库 | 极高 | 中等 | 需要安全存储的Android应用 |
| 自定义加密 | 可变 | 中等 | 特殊的安全要求 |
首先审查您的应用当前的令牌存储方法,然后实施这些最佳实践来保护您的用户和您的品牌。
Faux Disk Encryption Mobile 设备上的安全存储现实 - Daniel Mayer & Drew Suarez
安全令牌存储的基本规则
保护令牌需要多层安全措施。通过结合多个安全措施,确保如果一个措施失败,其他措施仍然保护敏感数据。对于 Capacitor 应用,遵循这些实践对于在各个平台上维护令牌安全至关重要。
使用 HTTPS 和证书固定
HTTPS 加密是您防止令牌截获的第一道防线。您的应用程序与服务器之间的每次交互都必须使用 HTTPS 来加密在传输中的数据,防止攻击者接触到数据。
为了进一步加强这一点,实施 证书固定. 对于 Capacitor 应用程序, @capgo/capacitor-ssl-pinning 固定 HTTPS 连接到 iOS 和 Android 上的 CapacitorHttp 的捆绑证书。这种技术确保您的应用程序始终与您信任的服务器通信,即使有人尝试使用伪造的证书。通过在应用程序中硬编码您的服务器的证书或公钥,您建立了应用程序和服务器之间的直接信任关系。
“您应该固定任何时候您想对远程主机的身份有相对确定的信心或在恶意环境中操作。由于这两种情况几乎总是为真,因此您应该固定所有时间。” – OWASP 固定指南 [5]
一个现实的例子:Twitter 在其移动应用程序中引入了证书固定,之后经历了 Man-in-the-Middle (MitM) 攻击。他们的团队将服务器的 SSL 证书公钥直接嵌入到应用程序中。当用户连接时,应用程序验证证书与固定证书是否匹配。如果没有匹配,连接立即终止。这一方法显著减少了 MitM 攻击和提高了用户对平台的信心 [5].
您可以选择 证书固定 (验证整个证书) 以获得最大安全性或 公钥固定 (仅验证公钥) 以便在证书续期时具有更大的灵活性。像这样的工具 OkHttp 用于 Android Alamofire 用于 iOS 简化了这些技术的实现 [5].
一旦安全传输就位,下一步就是最小化令牌暴露。
令牌暴露最小化
减少令牌暴露涉及限制令牌的范围和有效期。想法很简单:令牌的有效时间越短,权限越少,越低风险如果它被破坏。
- 使用 短期访问令牌 令牌有效期以分钟为单位。将它们与刷新令牌配对以保持用户会话而不保留长期访问令牌在设备上。这一方法确保盗窃的令牌迅速变得无用。
- 遵循最小权限原则。例如,如果令牌仅用于读取用户资料,则不应授予修改帐户设置或访问付款细节的权限。 为令牌启用刷新令牌旋转,新刷新令牌每次使用时都会发出新的访问令牌。如果刷新令牌被盗用,它将在合法应用使用后失效,从而减少风险窗口。通过限制令牌暴露,减少了由于违约造成的重大损害的机会。接下来,数据加密确保令牌即使设备物理受损,也保持安全。
- 在设备上存储令牌时使用数据加密。 数据加密在设备上存储令牌时提供保护,即使设备丢失、被盗或被恶意软件破坏,令牌也保持不可读。现代移动操作系统提供了安全、硬件支持的存储选项,这比标准方法如Android的SharedPreferences或iOS的NSUserDefaults要可靠得多。 [4].
在Android上
在iOS上
在iOS上 在iOS上
在iOS上 [4].
- 在iOS上: 使用
EncryptedSharedPreferences(可在 Android 10 及更高版本上使用)。该工具自动处理加密和密钥管理,简化了实现并提高了安全性。例如,SecureJWTStorage类可以安全地存储和检索 JWT 使用EncryptedSharedPreferences而无需进行复杂的自定义加密code。 - 对于 iOS: Keychain 提供硬件级别的加密用于安全令牌存储。开发人员可以使用
KeychainHelper类来管理 JWT令牌或通过在 Keychain 中存储令牌之前使用 CryptoKit 加密令牌以提供额外的安全性 [4].
Both Android 和 iOS 都利用硬件背后的加密,例如 iOS 上的 Secure Enclave 和 Android 上的 Hardware Security Module。这些组件将加密密钥存储在抗篡改硬件中,隔离于主操作系统。
最后,建立明确的数据保留政策。自动删除过期令牌并在不再需要时从设备中安全删除敏感数据。这些实践确保令牌只存储在绝对必要的时间内 [6].
平台特定的令牌存储方法
每个移动平台都提供了自己的工具来保护令牌,针对安全和用户体验的需求。这些本地选项基于核心实践,如HTTPS、加密和限制暴露,这些实践在前面已经讨论过。
Android:Keystore 和 EncryptedSharedPreferences

Android 设备通过 Keystore 系统和 EncryptedSharedPreferences 提供了强大的令牌保护。Keystore 系统安全存储加密密钥,在受保护的环境中,使其难以提取并确保它们不可导出。这意味着密钥只能用于安全操作。此外,您还可以添加限制,如要求用户身份验证。对于运行 Android 9(__CAPGO_KEEP_0__ 等级 28)或更高版本的设备, StrongBox KeyMint. The Keystore securely stores cryptographic keys in a protected environment, making them difficult to extract and ensuring they remain non-exportable. This means the keys can only be used for secure operations. Additionally, you can add restrictions like requiring user authentication. For devices running Android 9 (API level 28) or later, ,并使用 enable FEATURE_STRONGBOX_KEYSTORE它 KeyGenParameterSpec.Builder.setIsStrongBoxBacked().
EncryptedSharedPreferences 提供了一种更简单的方式来安全地存储键值对。它会对数据进行加密并安全地管理密钥,支持 API 等级 23 以上。安卓工程师 Arun 强调了其使用方便性:
“仅需几行 code,我们就可以显著提高安全性”, 通过使用它,我们可以 显著提高安全性
EncryptedSharedPreferences它是一个强大且易于使用的解决方案,用于在安卓应用中安全地存储敏感数据。”
为了最佳实践,应实现错误处理、每 90–180 天轮换密钥,并避免在 SharedPreferences 中存储高度敏感的数据(如信用卡号码)。此类数据应在安全的后端处理。
iOS:Keychain 和 Secure Enclave Keychain
Secure Enclave 在 iOS 上,令牌安全依赖于 Keychain 和 Secure Enclave。 Secure Enclave Keychain. The Keychain 是一个安全的存储库,用于敏感数据,如密码和令牌,使用 AES-256-GCM 加密。它采用双钥系统:一个用于元数据的钥匙和一个用于每个存储项的独特钥匙。元数据钥匙由 Secure Enclave 保护,缓存它们以实现更快的查找,秘密钥匙需要将其发送到 enclave 以实现额外的安全性。Keychain 还支持同一开发者应用之间的安全共享项,通过 daemon 管理。 securityd daemon.
Secure Enclave 提高了保护力,使用 P256 钥匙和约 4 MB 的安全存储。您可以通过配置访问控制列表(ACL)来进一步加强安全性,要求 Face ID、Touch ID 或密码验证使用设置如 kSecAttrAccessibleWhenUnlocked. .whenPasscodeSetThisDeviceOnly 选项确保数据与设备绑定,减少未经授权访问的风险。请务必处理边缘案例,如生物识别锁定或设备重置,以及定期审计应用权限和许可。
CapacitorSecure Storage Plugin

For cross-platform apps, Capacitor offers secure storage plugins that simplify token security without requiring platform-specific code. @capgo/capacitor-data-storage-sqlite Capacitor @capgo/capacitor-persistent-account 跨重装时保留认证数据。 在 iOS 上,插件将数据存储在加密的系统 Keychain 中,而在 Android 上,它使用 AES 在 GCM 模式下加密数据,使用由 Android Keystore 生成的密钥,然后将其保存在 SharedPreferences 中。 在 web 环境中,插件使用未加密的 localStorage - 但仅用于调试目的。
2025 年 2 月,martinkasa 更新了 capacitor-secure-storage-plugin 以支持 Capacitor v7,确保了 iOS 和 Android 上的字符串值的安全存储。 这些插件适合用于存储登录凭证和 JSON 数据。 然而,它们可能缺乏原生解决方案提供的细粒度控制。 对于具有高级安全需求的企业级应用,原生选项如 iOS Keychain Services 和 Android Keystore APIs - 或增强的工具如 Ionic’s Identity Vault - 可能更合适。 Capacitor 的官方文档还建议使用原生安全存储来存储敏感数据,例如加密密钥或会话令牌。
当部署 Capacitor 应用的实时更新时,服务如 Capgo 可以进一步增强令牌安全性。 Capgo 的端到端加密确保了更新 - 包括包含安全补丁或令牌管理改进的更新 - 将安全地传递,维护应用安全框架的完整性。
管理令牌生命周期和安全性
有效的令牌管理涉及监控令牌的创建、过期和撤销。开发者需要设计系统,既能提供强大的安全措施,又能为用户提供流畅的体验。以下,我们将探讨令牌过期、撤销和安全的OTA更新策略,以帮助您构建全面令牌管理方案。
令牌过期和刷新方法
使用短期访问令牌和长期刷新令牌是安全令牌处理的关键实践。访问令牌应在5-15分钟内过期,以减少被泄露的风险。另一方面,刷新令牌可以保持有效数天或数周,允许用户保持会话而不需要频繁重新验证。
令牌过期在保持API安全和高效方面起着至关重要的作用 [7].将令牌过期与令牌轮换(先前发行的令牌被invalidated)结合起来,会提供额外的保护。这种方法可以最小化因刷新令牌被泄露而造成的损害,并且可以帮助识别可疑活动,如旧令牌的重用。
设计刷新机制时,务必在刷新过程中严格验证令牌。使用速率限制来防止暴力攻击,并使用自动监控来检测异常情况,如同一时间来自多个位置的刷新请求。平衡安全性和性能是保护用户会话而不影响整体体验的关键。
令牌撤销和失效
虽然令牌失效是至关重要的,但令牌撤销在用户注销、丢失设备或疑似安全漏洞等场景中提供了另一个安全层。尽管无状态JWT访问令牌在失效前保持有效,但有效管理刷新令牌可以阻止新访问令牌的颁发。
及时撤销令牌可以防止未经授权的访问敏感资源 [8]为了立即失效令牌,考虑在服务器端实现一个黑名单来跟踪撤销令牌并在API请求期间检查它们。此外,单点注销(SLO)功能允许用户在一个操作中终止多个身份验证会话,从而确保所有相关的刷新令牌在连接的服务中都被撤销。
在处理被破坏的令牌时,也很重要。这些协议应该包括立即令牌撤销、自动安全警报、及时通知受影响用户以及与被破坏令牌相关的所有活动会话的终止。
安全令牌更新与OTA系统
一旦您建立了强大的令牌生命周期和撤销策略,安全的OTA更新就变得至关重要,以应对不断演变的威胁。OTA系统允许您快速部署安全补丁、旋转API密钥、更新证书和精细化验证逻辑—all不需要用户手动更新。
使用Capacitor的开发者,可以使用工具Capgo来获得符合OTA的解决方案,具有端到端的加密。这确保了安全更新可以安全地传递到设备,同时遵守苹果和安卓的指南。这样的系统尤其适合解决紧急安全漏洞。
为了进一步增强令牌安全,监控您的应用程序和基础设施以应对新兴威胁。使用OTA系统来部署运行时防御和其他先进措施,可以立即阻止可疑用户或设备,同时确保对合法用户的服务不受影响。
令牌存储选项比较:安全性与易用性
在决定如何安全存储令牌时,关键是找到安全性和易用性的平衡。您的选择直接影响应用程序的易受攻击性以及用户体验。让我们分解不同存储方法的权衡。
内存存储与持久存储
内存存储 将令牌存储在应用程序内存或JavaScript变量中,使其成为一个高度安全的选项。由于令牌没有写入 持久存储攻击者使用传统的 XSS 攻击时,攻击者有更少的机会访问它们。
但是,有一个陷阱:存储在内存中的令牌会在用户刷新页面或打开新标签时消失。这使得在内存中存储的令牌对于需要提供平滑浏览体验的 Web 应用来说不太实用。
另一方面, 持久性存储 - 本地存储、会话存储或 cookie 等方法 - 提供了更平滑的体验。持久性存储的令牌允许用户关闭浏览器,稍后返回并从上次离开的地方继续使用,而无需再次登录。 [9].
然而,这种便利性伴随着安全风险。持久性存储更容易受到 XSS 攻击,恶意脚本可以从本地或会话存储中窃取令牌。 [4],
For mobile apps using Capacitor, 提供了一个中间地带。它们在一个单独的全局范围内运行,增强了安全性,同时比内存存储更好地维护了可用性。 如果 Web Worker 不是可用的选项,JavaScript 闭包可以模拟私有方法来添加额外的保护层。 [9]移动开发者还需要权衡原生安全存储与自定义加密的利弊。 [9]__CAPGO_KEEP_0__
Keychain/Keystore vs. 自定义加密
对于移动应用来说, 使用平台原生安全存储 如 iOS Keychain 和 Android Keystore 是金标准。这些解决方案提供了硬件级别的安全性,使得令牌提取变得更加困难。
The beauty of these native tools lies in their simplicity. They’re built into the operating systems, so developers don’t have to write extensive code to implement them. Plus, they support features like 生物识别认证 和集中化凭证管理 [10].
这两种功能都可以提高安全性和用户体验自定义加密 [10]另一方面,给开发人员更多的控制权,但带来了显著的挑战。安全性完全依赖于加密的实现以及密钥的管理
。许多开发人员低估了创建安全系统的复杂性,这可能会导致漏洞。由于加密标准不断演进,自定义解决方案需要持续的更新和维护,这使得它们成为资源密集型的解决方案,除非您的团队在这个领域有深厚的专长。
| 安全性与可用性比较表格 | 安全级别 | 易用性 | 实现复杂度 | 最佳使用场景 |
|---|---|---|---|---|
| 内存存储 | 高 | 刷新后丢失(低) | 低 | 高安全性,短会话 |
| 本地存储 | 低 | 高 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| 非敏感数据 | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | 临时会话数据 |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ | 具有服务器支持的Web应用 |
| iOS Keychain | 极高 | 中等 | 低 | iOS原生/混合应用 |
| Android Keystore | 极高 | 中等 | 低 | Android原生/混合应用 |
| 自定义加密 | 可变 | Medium | High | 专属安全需求 |
本表强调了平台本地存储选项,如Keychain和Keystore,提供了强大的安全性和易于实现的组合,使其成为移动应用的理想选择。它们提供了强大的保护,而不需要开发者掌握加密技术。
对于Capacitor开发者来说,使用安全存储插件来访问这些本机解决方案是一个明智的决定。它结合了Keychain和Keystore的硬件背后的安全性与Capacitor提供的跨平台灵活性。
最终,您的令牌存储选择应与您的应用程序的威胁模型和用户期望相一致。处理敏感数据的应用程序,例如医疗保健或金融应用程序,应将安全性置于一切之上。相反,面向消费者的应用程序可能会接受更高的风险以提供更Smooth的用户体验。通过了解这些权衡,您可以选择最适合您的需求的存储方法。
关键点
通过安全令牌存储保护用户数据,不仅是技术最佳实践,而且是维护应用程序完整性的必要条件。根据 2022年确认的漏洞中有81%与弱、重复或盗用的密码有关 [12],移动开发者需要优先考虑强大的令牌安全措施。
最佳实践摘要
有效的令牌安全计划依赖于多层保护。首先使用 使用本地原生安全存储,例如 iOS Keychain 和 Android Keystore,提供硬件级别的安全性。
避免将令牌存储在 LocalStorage 或 IndexedDB 中 [2],因为这些方法容易受到 XSS 攻击。相反,依赖于操作系统内置的安全存储选项,确保访问权限有限。对于使用 Capacitor 的开发者,安全存储插件提供了一个方法来利用原生保护,同时保持跨平台功能。
令牌生命周期管理是另一个关键方面。定期过期令牌并实现刷新令牌轮换,生成一个新的刷新令牌每次请求访问令牌 [3].较短的刷新令牌寿命可以减少在被盗窃的情况下滥用的风险。
保密签名密钥,仅与必要的服务共享 [1].避免不安全的做法,如记录令牌或将其嵌入到 URL 中 [11].这些步骤共同加强了令牌管理策略。
开发者下一步
context
-
Page/area: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Message key `native_build_builder_credit_next` (Native Build Builder Credit Next). 如果您正在使用不安全的解决方案,如LocalStorage,优先考虑迁移到平台原生安全存储。对于Capacitor应用程序,采用安全存储插件以有效利用原生保护。
-
实施层次式认证。 对于低风险操作使用简单的方法,但要求 多因素认证 (MFA)或生物识别 [12]对于敏感操作。根据Microsoft的说法,MFA可以阻止99.9%的自动化网络攻击 [12].
-
但是,考虑用户体验-研究表明,约三分之一的用户避免MFA是因为其不便 for secure and immediate rollouts. Tools like Capgo enable encrypted live updates for Capacitor apps, ensuring that security fixes reach users without compromising token safety during updates.
-
进行安全和即时的发布。工具如__CAPGO_KEEP_0__可为__CAPGO_KEEP_1__应用程序启用加密的实时更新,确保安全修复可以安全地到达用户,而不会在更新期间损害令牌安全。 关注令牌生命周期管理。
-
定期过期、刷新和注销协议至关重要。确保您的实现反映了这些原则,以限制风险。 监控认证模式。 [13] . 应该成为开发过程中常规的一部分,而不是临时考虑的事项。
虽然移动安全还在不断演进,但核心原则仍然相同:使用本机安全存储、有效管理令牌生命周期以及确保加密不可动摇。随着 截至2022年,智能手机中有81%已配备了生物识别功能 作为 [12]开发者有了强大的工具来提高安全性和用户体验。
您的用户正在将数据托管给您 - 确保令牌存储实践符合最高的安全标准。
常见问题
::: faq
为什么移动开发者应该使用iOS Keychain和Android Keystore进行安全令牌存储?
使用本机安全存储,例如iOS Keychain和Android Keystore,能够在移动应用程序中保护敏感数据。这些工具具有 内置加密,确保令牌不会被未经授权的访问。除此之外,它们还包含 用户身份验证需要用户确认身份后才能访问存储的数据。这增加了一个额外的安全层。
其中一个突出的特点是 不可导出的加密密钥。换句话说,这些密钥无法从设备中移除,这显著降低了它们被破坏的风险。由于这些系统旨在与其各自平台无缝集成,开发人员可以轻松地将它们实施,从而避免手动处理复杂的加密过程的麻烦。利用这些工具不仅可以增强应用程序的安全性,还可以帮助开发人员满足 现代安全标准 和遵循 行业推荐的最佳实践. :::
::: faq
什么是移动应用程序中安全管理令牌生命周期的最佳实践?
在移动应用程序中安全地处理令牌生命周期,开发人员应该坚持几个基本的实践。首先使用 短期令牌例如那些15分钟过期的令牌。这样可以最小化令牌被泄露的窗口。为了保持用户的便利性而不损害安全性,实现 令牌刷新.这些令牌允许在不迫使用户重复登录的情况下重新发行令牌。
令牌的正确存储对于防止未经授权的访问至关重要。始终依赖平台特定的安全存储解决方案,如 Keychain 或 Android Keystore.这些是专门设计来保护敏感数据的。另外,避免在应用程序中硬编码令牌或将它们存储在明文中,因为这可能会使它们暴露于潜在威胁中。
通过集成这些实践,开发者可以增强移动应用程序中的令牌管理安全性并保护用户免受潜在漏洞的侵害。 :::
::: faq
在令牌存储中使用自定义加密会带来什么挑战,何时应该优先考虑本机解决方案?
在移动应用程序中存储令牌时,使用自定义加密可能是一个双刃剑。虽然它可能看起来像一个定制解决方案提供了更多的控制,但它通常会带来额外的复杂性,打开安全漏洞的门户,并要求持续维护以应对新威胁。与平台提供的内置加密工具不同,自定义解决方案通常缺乏广泛的测试、详细的文档和强大的开发者社区的支持。这使得调试和集成变得更加困难。
说到这一点,确实有情况需要自定义加密——例如,当您处理极其敏感的数据或试图满足标准工具无法处理的严格法规要求时。 在这些情况下,开发人员必须遵循 最佳实践 以确保他们的 加密方法 不仅安全,还可靠且符合行业标准。 在选择自定义加密方法之前,务必仔细考虑权衡。
继续阅读:Secure Token Storage: Mobile Developers的安全存储最佳实践
如果您正在使用 Secure Token Storage: Mobile Developers的安全存储最佳实践 来规划安全性和合规性,连接它与 加密 加密 加密 为 Compliance 的实现细节 Capgo 安全扫描器 为 Capgo 安全扫描器 的产品工作流程 Capgo 安全 为 Capgo 安全 的产品工作流程 Capgo 信任中心 为 Capgo 信任中心 的产品工作流程