移动应用身份验证架构¶

身份验证和授权问题是普遍存在的安全漏洞。事实上，它们始终在 OWASP Top 10 中排名第二。

大多数移动应用程序都实现了某种用户身份验证。即使身份验证和状态管理逻辑的一部分由后端服务执行，但身份验证是大多数移动应用架构不可或缺的一部分，因此了解其常见实现非常重要。

由于基本概念在 iOS 和 Android 上是相同的，我们将在本通用指南中讨论流行的身份验证和授权架构以及陷阱。操作系统特定的身份验证问题（例如本地和生物识别身份验证）将在各自的操作系统特定章节中讨论。

一般假设¶

已实施适当的身份验证¶

测试身份验证和授权时，请执行以下步骤

识别应用程序使用的其他身份验证因素。
找到提供关键功能的所有端点。
验证是否在所有服务器端点上严格强制执行其他因素。

当未在服务器上一致地强制执行身份验证状态，并且客户端可以篡改状态时，存在身份验证绕过漏洞。当后端服务处理来自移动客户端的请求时，它必须始终强制执行授权检查：每次请求资源时都验证用户是否已登录并已获得授权。

考虑以下来自 OWASP Web Testing Guide 的示例。在该示例中，通过 URL 访问 Web 资源，身份验证状态通过 GET 参数传递

http://www.site.com/page.asp?authenticated=no

客户端可以任意更改随请求发送的 GET 参数。没有什么能阻止客户端简单地将 authenticated 参数的值更改为“yes”，从而有效地绕过身份验证。

虽然这是一个简单的示例，您可能不会在实际环境中找到它，但程序员有时会依赖“隐藏的”客户端参数（例如 cookie）来维护身份验证状态。他们假设这些参数不能被篡改。例如，考虑以下 Nortel Contact Center Manager 中的经典漏洞。 Nortel 设备的管理 Web 应用程序依赖于 cookie "isAdmin" 来确定是否应授予登录用户管理权限。因此，可以通过简单地设置 cookie 值来获得管理员访问权限，如下所示

isAdmin=True

安全专家过去常常建议使用基于会话的身份验证，并且仅在服务器上维护会话数据。这可以防止以任何形式篡改客户端会话状态。但是，使用无状态身份验证而不是基于会话的身份验证的全部意义在于在服务器上没有会话状态。相反，状态存储在客户端令牌中，并随每个请求一起传输。在这种情况下，看到诸如 isAdmin 之类的客户端参数是完全正常的。

为了防止篡改，加密签名被添加到客户端令牌。当然，事情可能会出错，无状态身份验证的流行实现容易受到攻击。例如，可以通过将签名类型设置为 "None" 来禁用某些 JSON Web Token (JWT) 实现的签名验证。

密码的最佳实践¶

使用密码进行身份验证时，密码强度是一个关键问题。密码策略定义了最终用户应遵守的要求。密码策略通常指定密码长度、密码复杂性和密码拓扑。 “强”密码策略使手动或自动密码破解变得困难或不可能。有关更多信息，请查阅 OWASP Authentication Cheat Sheet。

身份验证测试的一般准则¶

没有一种通用的身份验证方法。在审查应用程序的身份验证架构时，您应首先考虑在给定的上下文中使用的身份验证方法是否合适。身份验证可以基于以下一项或多项

用户知道的东西（密码、PIN、图案等）
用户拥有的东西（SIM 卡、一次性密码生成器或硬件令牌）
用户的生物识别属性（指纹、视网膜、声音）

移动应用程序实施的身份验证过程的数量取决于功能或访问资源的敏感性。在审查身份验证功能时，请参考行业最佳实践。对于具有用户登录且不太敏感的应用程序，通常认为用户名/密码身份验证（与合理的密码策略相结合）就足够了。大多数社交媒体应用程序都使用这种形式的身份验证。

对于敏感应用程序，通常适合添加第二个身份验证因素。这包括提供对非常敏感的信息（例如信用卡号）的访问权限或允许用户转移资金的应用程序。在某些行业中，这些应用程序还必须符合某些标准。例如，金融应用程序必须确保符合支付卡行业数据安全标准 (PCI DSS)、Gramm Leach Bliley 法案和 Sarbanes-Oxley 法案 (SOX)。美国医疗保健行业的合规性考虑因素包括健康保险流通与责任法案 (HIPAA) 和患者安全规则。

有状态与无状态身份验证¶

您通常会发现移动应用程序使用 HTTP 作为传输层。 HTTP 协议本身是无状态的，因此必须有一种方法将用户后续的 HTTP 请求与该用户关联起来。否则，用户的登录凭据必须随每个请求一起发送。此外，服务器和客户端都需要跟踪用户数据（例如，用户的权限或角色）。这可以通过两种不同的方式完成

对于有状态身份验证，当用户登录时会生成唯一的会话 ID。在后续请求中，此会话 ID 用作对服务器上存储的用户详细信息的引用。会话 ID 是不透明的；它不包含任何用户数据。
对于无状态身份验证，所有用户识别信息都存储在客户端令牌中。令牌可以传递给任何服务器或微服务，从而无需在服务器上维护会话状态。无状态身份验证通常被分解为授权服务器，该服务器在用户登录时生成、签名并可选择加密令牌。

Web 应用程序通常使用有状态身份验证，其中随机会话 ID 存储在客户端 cookie 中。虽然移动应用程序有时以类似的方式使用有状态会话，但基于无状态令牌的方法正变得越来越流行，原因如下

它们通过消除在服务器上存储会话状态的需要来提高可扩展性和性能。
令牌使开发人员能够将身份验证与应用程序分离。令牌可以由身份验证服务器生成，并且可以无缝更改身份验证方案。

作为移动安全测试人员，您应该熟悉这两种类型的身份验证。

有状态身份验证¶

有状态（或“基于会话”）身份验证的特征在于客户端和服务器上都有身份验证记录。身份验证流程如下

应用程序将包含用户凭据的请求发送到后端服务器。
服务器验证凭据。如果凭据有效，服务器会创建一个新会话以及一个随机会话 ID。
服务器向客户端发送一个响应，其中包含会话 ID。
客户端随所有后续请求一起发送会话 ID。服务器验证会话 ID 并检索关联的会话记录。
用户注销后，服务器端会话记录将被销毁，客户端将丢弃会话 ID。

当会话管理不当时，它们容易受到各种攻击，这些攻击可能会危及合法用户的会话，从而使攻击者能够冒充用户。这可能会导致数据丢失、机密性泄露和非法操作。

最佳实践

找到提供敏感信息或功能的任何服务器端点，并验证授权的一致强制执行。后端服务必须验证用户的会话 ID 或令牌，并确保用户具有足够的权限来访问资源。如果会话 ID 或令牌丢失或无效，则必须拒绝该请求。

确保

会话 ID 在服务器端随机生成。
ID 不容易被猜到（使用适当的长度和熵）。
会话 ID 始终通过安全连接（例如 HTTPS）交换。
移动应用程序不会将会话 ID 保存在永久存储中。
每当用户尝试访问特权应用程序元素时，服务器都会验证会话（会话 ID 必须有效并且必须对应于正确的授权级别）。
会话在服务器端终止，并且在超时或用户注销后，会话信息在移动应用程序中删除。

不应从头开始实施身份验证，而应在经过验证的框架之上构建。许多流行的框架都提供现成的身份验证和会话管理功能。如果应用程序使用框架 API 进行身份验证，请查看框架安全文档以了解最佳实践。以下链接提供了常见框架的安全指南

OWASP Web Testing Guide 是测试服务器端身份验证的绝佳资源，特别是 Testing Authentication 和 Testing Session Management 章节。

无状态身份验证¶

基于令牌的身份验证是通过随每个 HTTP 请求一起发送签名令牌（由服务器验证）来实现的。最常用的令牌格式是在 RFC7519 中定义的 JSON Web Token。 JWT 可以将完整的会话状态编码为 JSON 对象。因此，服务器不必存储任何会话数据或身份验证信息。

JWT 令牌由三个 Base64Url 编码的部分组成，这些部分以点分隔。令牌结构如下

base64UrlEncode(header).base64UrlEncode(payload).base64UrlEncode(signature)

以下示例显示了一个 Base64Url 编码的 JSON Web Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikpva
G4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

header 通常由两个部分组成：令牌类型（即 JWT）和用于计算签名的哈希算法。在上面的示例中，标头解码如下

{"alg":"HS256","typ":"JWT"}

令牌的第二部分是 payload，其中包含所谓的声明。声明是关于实体（通常是用户）和其他元数据的语句。例如

{"sub":"1234567890","name":"John Doe","admin":true}

签名是通过将 JWT 标头中指定的算法应用于编码标头、编码负载和秘密值来创建的。例如，当使用 HMAC SHA256 算法时，签名按以下方式创建

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

请注意，密钥在身份验证服务器和后端服务之间共享 - 客户端不知道它。这证明令牌是从合法的身份验证服务获得的。它还可以防止客户端篡改令牌中包含的声明。

最佳实践

验证实现是否符合 JWT 最佳实践

验证是否为所有包含令牌的传入请求检查了 HMAC。
验证私钥签名密钥或 HMAC 密钥是否从未与客户端共享。它应该仅对颁发者和验证者可用。
验证 JWT 中是否未嵌入敏感数据，例如个人身份信息。例如，通过解码 base64 编码的 JWT 并找出它传输的数据类型以及该数据是否已加密。如果由于某种原因，架构要求在此令牌中传输此类信息，请确保应用负载加密。
确保使用 jti（JWT ID）声明解决重放攻击，该声明为 JWT 提供唯一标识符。
确保使用 aud（受众）声明解决跨服务中继攻击，该声明定义了令牌授权给哪个应用程序。
验证令牌是否安全地存储在手机上，例如使用 KeyChain (iOS) 或 KeyStore (Android)。
验证哈希算法是否已强制执行。一种常见的攻击包括更改令牌以使用空签名（例如，signature = ""）并将签名算法设置为 none，指示“令牌的完整性已经过验证”。某些库可能会将使用 none 算法签名的令牌视为已验证签名的有效令牌，因此应用程序将信任更改后的令牌声明。
验证令牌是否包含 "exp" 过期声明，并且后端不处理过期的令牌。授予令牌的一种常用方法是结合使用访问令牌和刷新令牌。当用户登录时，后端服务会颁发一个短期的访问令牌和一个长期的刷新令牌。然后，如果访问令牌过期，应用程序可以使用刷新令牌来获取新的访问令牌。

有两种不同的 Burp 插件可以帮助您测试上面列出的漏洞

此外，请务必查看 OWASP JWT Cheat Sheet 以获取更多信息。

OAuth 2.0¶

OAuth 2.0 是一个授权框架，使第三方应用程序能够获得对远程 HTTP 服务（例如 API 和支持 Web 的应用程序）上的用户帐户的有限访问权限。

OAuth2 的常见用途包括

获取用户许可，以使用其帐户访问在线服务。
代表用户向在线服务进行身份验证。
处理身份验证错误。

根据 OAuth 2.0，寻求访问用户资源的移动客户端必须首先要求用户针对身份验证服务器进行身份验证。在获得用户批准后，授权服务器将颁发一个令牌，允许应用程序代表用户执行操作。请注意，OAuth2 规范未定义任何特定类型的身份验证或访问令牌格式。

协议概述¶

OAuth 2.0 定义了四个角色

资源所有者：帐户所有者
客户端：希望使用访问令牌访问用户帐户的应用程序
资源服务器：托管用户帐户
授权服务器：验证用户身份并向应用程序颁发访问令牌

注意：API 履行资源服务器和授权服务器的角色。因此，我们将两者都称为 API。

以下是有关图中步骤的更详细说明

应用程序请求用户授权以访问服务资源。
如果用户授权该请求，则应用程序会收到授权许可。授权许可可能采用多种形式（显式、隐式等）。
应用程序通过出示自己的身份验证以及授权许可，从授权服务器 (API) 请求访问令牌。
如果应用程序身份已通过身份验证且授权许可有效，则授权服务器 (API) 会向应用程序颁发访问令牌，从而完成授权过程。访问令牌可能具有配套的刷新令牌。
应用程序从资源服务器 (API) 请求资源，并提供访问令牌以进行身份验证。访问令牌可以使用多种方式（例如，作为不记名令牌）。
如果访问令牌有效，则资源服务器 (API) 会将资源提供给应用程序。

在 OAuth2 中，用户代理是执行身份验证的实体。 OAuth2 身份验证可以通过外部用户代理（例如 Chrome 或 Safari）或在应用程序本身中执行（例如，通过嵌入到应用程序中的 WebView 或身份验证库）。这两种模式都不是本质上“更好”的。选择取决于应用程序的特定用例和威胁模型。

外部用户代理： 对于需要与社交媒体帐户（Facebook、Twitter 等）交互的应用程序，应选择使用外部用户代理的方法。此方法的优点包括

用户的凭据永远不会直接暴露给应用程序。这保证了应用程序无法在登录过程中获取凭据（“凭据网络钓鱼”）。
几乎不需要将身份验证逻辑添加到应用程序本身，从而防止编码错误。

从负面方面来看，无法控制浏览器的行为（例如，激活证书固定）。

嵌入式用户代理： 对于需要在封闭生态系统中运行的应用程序，例如与公司帐户交互，应选择使用嵌入式用户代理的方法。例如，考虑一个银行应用程序，该应用程序使用 OAuth2 从银行的身份验证服务器检索访问令牌，然后使用该访问令牌访问多个微服务。在这种情况下，凭据网络钓鱼不是可行的方案。最好将身份验证过程保留在（希望）精心保护的银行应用程序中，而不是信任外部组件。

最佳实践¶

有关其他最佳实践和详细信息，请参阅以下源文档

一些最佳实践包括但不限于

用户代理
- 用户应有一种方法可以直观地验证信任（例如，传输层安全性 (TLS) 确认、网站机制）。
- 为了防止中间人 (MITM) 攻击，客户端应使用服务器在建立连接时提供的公钥来验证服务器的完全限定域名。
授权类型
- 在原生应用程序上，应使用代码授权而不是隐式授权。
- 当使用代码授权时，应实施 PKCE（代码交换的证明密钥）来保护代码授权。确保服务器也实施它。
- auth "code" 应该是短期的，并且在收到后立即使用。验证授权码是否仅驻留在临时内存中，并且未存储或记录。
客户端密钥
- 不应使用共享密钥来证明客户端的身份，因为客户端可能会被冒充（“client_id”已经用作证明）。如果他们确实使用客户端密钥，请确保它们存储在安全的本地存储中。
最终用户凭据
- 使用传输层方法（例如 TLS）保护最终用户凭据的传输。
令牌
- 将访问令牌保存在临时内存中。
- 访问令牌必须通过加密连接传输。
- 当无法保证端到端机密性或令牌提供对敏感信息或交易的访问权限时，请减少访问令牌的范围和持续时间。
- 请记住，如果应用程序使用访问令牌作为不记名令牌，而没有其他方法来识别客户端，则窃取令牌的攻击者可以访问它们的范围以及所有与其关联的资源。
- 将刷新令牌存储在安全的本地存储中；它们是长期凭据。

用户注销¶

未能销毁服务器端会话是最常见的注销功能实现错误之一。即使在用户注销应用程序后，此错误也会使会话或令牌保持活动状态。获得有效身份验证信息的攻击者可以继续使用它并劫持用户的帐户。

许多移动应用程序不会自动注销用户。可能有多种原因，例如：因为它对客户不方便，或者因为在实施无状态身份验证时做出的决定。应用程序仍然应该具有注销功能，并且应该按照最佳实践来实施，销毁所有本地存储的令牌或会话标识符。

如果会话信息存储在服务器上，则应通过向该服务器发送注销请求来销毁它。在高风险应用程序的情况下，应使令牌无效。如果泄漏令牌，不删除令牌或会话标识符可能会导致未经授权访问应用程序。请注意，其他敏感类型的信息也应该删除，因为任何未正确清除的信息都可能稍后泄漏，例如在设备备份期间。

以下是用于正确服务器端注销的会话终止的不同示例

如果访问和刷新令牌与无状态身份验证一起使用，则应从移动设备中删除它们。应在服务器上使刷新令牌无效。

OWASP Web Testing Guide (WSTG-SESS-06) 包含详细说明和更多测试用例。

补充身份验证¶

身份验证方案有时会通过被动上下文身份验证进行补充，该身份验证可以包含

地理位置
IP 地址
一天中的时间
正在使用的设备

理想情况下，在这种系统中，用户的上下文会与先前记录的数据进行比较，以识别可能表明帐户滥用或潜在欺诈的异常情况。此过程对用户是透明的，但可以成为对攻击者的强大威慑。

双因素身份验证¶

双因素身份验证 (2FA) 是允许用户访问敏感功能和数据的应用程序的标准配置。常见的实现使用密码作为第一个因素，并使用以下任何一项作为第二个因素

通过短信发送的一次性密码 (SMS-OTP)
通过电话拨打的一次性代码
硬件或软件令牌
推送通知与 PKI 和本地身份验证结合使用

无论使用哪个选项，都必须在服务器端强制执行和验证，而不是在客户端强制执行和验证。否则，2FA 很容易在应用程序中被绕过。

2FA 可以在登录时或稍后在用户的会话中执行。

例如，在使用用户名和 PIN 码登录到银行应用程序后，用户有权执行非敏感任务。一旦用户尝试执行银行转账，就必须提供第二个因素（“升级身份验证”）。

最佳实践

不要自己推出 2FA：有多种双因素身份验证机制可用，范围从第三方库、外部应用程序的使用到开发人员自己实施的检查。
使用短期的 OTP：OTP 应仅在特定时间段内有效（通常为 30 秒），并且在错误地键入 OTP 几次（通常为 3 次）后，应使提供的 OTP 无效，并且用户应被重定向到目标页面或注销。
安全地存储令牌：为了防止此类攻击，应用程序应始终验证某种用户令牌或与先前安全存储的用户相关的其他动态信息（例如在 Keychain/KeyStore 中）。

短信验证码¶

虽然通过短信发送的一次性密码 (OTP) 是双因素身份验证的常见第二因素，但此方法存在缺点。 2016 年，NIST 建议：“由于短信可能被拦截或重定向的风险，新系统的实施者应仔细考虑替代身份验证器。”。您将在下面找到一些相关威胁和避免对短信验证码的成功攻击的建议的列表。

威胁

无线拦截：攻击者可以通过滥用毫微微蜂窝和其他电信网络中的已知漏洞来拦截短信。
特洛伊木马：已安装的具有访问文本消息权限的恶意应用程序可能会将 OTP 转发到另一个号码或后端。
SIM 卡交换攻击：在此攻击中，攻击者呼叫电话公司，或为其工作，并将受害者的号码转移到攻击者拥有的 SIM 卡上。如果成功，攻击者可以看到发送到受害者电话号码的短信。这包括双因素身份验证中使用的消息。
验证码转发攻击：这种社会工程攻击依赖于用户对提供 OTP 的公司的信任。在此攻击中，用户收到一个代码，随后被要求使用接收信息的相同方式中继该代码。
语音信箱：某些双因素身份验证方案允许在不再首选或无法使用短信时通过电话发送 OTP。如果未接听，许多此类呼叫会将信息发送到语音信箱。如果攻击者能够访问语音信箱，他们也可以使用 OTP 来访问用户的帐户。

您可以在下面找到一些在使用短信进行 OTP 时降低利用可能性的建议

消息传递：通过短信发送 OTP 时，请务必包含一条消息，让用户知道 1) 如果他们没有请求代码该怎么做 2) 您的公司绝不会致电或发短信给他们，要求他们中继密码或代码。
专用通道：当使用操作系统推送通知功能（iOS 上的 APN 和 Android 上的 FCM）时，可以将 OTP 安全地发送到注册的应用程序。与短信相比，此信息无法被其他应用程序访问。除了 OTP 之外，推送通知还可以触发弹出窗口以批准请求的访问。
熵：使用具有高熵的身份验证器，使 OTP 更难以破解或猜测，并使用至少 6 位数字。如果人们必须记住它们才能将它们复制到您的应用程序，请确保将数字分成更小的组。
避免使用语音信箱：如果用户希望接听电话，请不要将 OTP 信息作为语音信箱留言。

短信验证码研究

[#dmitrienko] Dmitrienko, Alexandra, et al. "On the (in) security of mobile two-factor authentication." International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2014.
[#grassi] Grassi, Paul A., et al. Digital identity guidelines: Authentication and lifecycle management (DRAFT). No. Special Publication (NIST SP)-800-63B. 2016.
[#grassi2] Grassi, Paul A., et al. Digital identity guidelines: Authentication and lifecycle management. No. Special Publication (NIST SP)-800-63B. 2017.
[#konoth] Konoth, Radhesh Krishnan, Victor van der Veen, and Herbert Bos. "How anywhere computing just killed your phone-based two-factor authentication." International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2016.
[#mulliner] Mulliner, Collin, et al. "基于短信的一次性密码：攻击与防御。" 国际入侵检测和恶意软件以及漏洞评估会议。 Springer，柏林，海德堡，2013。
[#siadati] Siadati, Hossein, et al. "注意您的短信：减轻双因素认证中的社会工程。" 计算机与安全 65 (2017): 14-28。
[#siadati2] Siadati, Hossein, Toan Nguyen, and Nasir Memon. "验证码转发攻击（简报）。" 国际密码会议。 Springer，查姆，2015。

使用推送通知和 PKI 进行交易签名¶

另一种替代且强大的实现第二因素的机制是交易签名。

交易签名需要验证用户对关键交易的批准。非对称加密是实现交易签名的最佳方式。应用程序将在用户注册时生成一个公钥/私钥对，然后在后端注册公钥。私钥安全地存储在 KeyStore (Android) 或 KeyChain (iOS) 中。为了授权交易，后端会向移动应用程序发送包含交易数据的推送通知。然后，系统会询问用户确认或拒绝交易。确认后，系统会提示用户解锁 Keychain（通过输入 PIN 或指纹），并且数据会使用用户的私钥进行签名。然后，签名的交易会发送到服务器，服务器使用用户的公钥验证签名。

应用程序应告知用户应用程序内的所有登录活动，并允许阻止某些设备，这是一种最佳实践。这可以分解为各种场景

当用户的帐户在另一设备上使用时，应用程序会立即提供推送通知，以通知用户不同的活动。然后，用户可以在通过推送通知打开应用程序后阻止此设备。
应用程序在登录后提供上次会话的概述。如果之前的会话与当前配置相比具有不同的配置（例如，位置、设备、应用程序版本），则用户应可以选择报告可疑活动并阻止上一次会话中使用的设备。
应用程序始终在登录后提供上次会话的概述。
应用程序具有一个自助服务门户，用户可以在其中查看审计日志。这允许用户管理已登录的不同设备。

开发人员可以利用特定的元信息并将其与应用程序中的每个不同活动或事件相关联。这将使用户更容易发现可疑行为并阻止相应的设备。元信息可能包括

设备：用户可以清楚地识别正在使用该应用程序的所有设备。
日期和时间：用户可以清楚地看到上次使用该应用程序的日期和时间。
位置：用户可以清楚地识别上次使用该应用程序的位置。

应用程序可以提供一个活动历史记录列表，该列表将在应用程序中每次敏感活动后更新。需要根据应用程序处理的数据以及团队愿意承担的安全风险，为每个应用程序选择要审计的活动。以下是通常审计的常见敏感活动列表

登录尝试
密码更改
个人身份信息更改（姓名、电子邮件地址、电话号码等）
敏感活动（购买、访问重要资源等）
同意条款和条件条款

付费内容需要特别注意，并且可能会使用其他元信息（例如，运营成本、信用等）以确保用户了解整个运营的参数。

此外，非抵赖机制应应用于敏感交易（例如，付费内容访问、同意条款和条件条款等），以证明特定交易实际上已执行（完整性）并由谁执行（身份验证）。

最后，用户应该可以注销特定的开放会话，并且在某些情况下，完全阻止使用设备标识符的某些设备可能很有趣。

移动应用身份验证架构¶

一般假设¶

已实施适当的身份验证¶

密码的最佳实践¶

身份验证测试的一般准则¶

有状态与无状态身份验证¶

有状态身份验证¶

无状态身份验证¶

OAuth 2.0¶

协议概述¶

最佳实践¶

用户注销¶

补充身份验证¶

双因素身份验证¶

短信验证码¶

使用推送通知和 PKI 进行交易签名¶

登录活动和设备阻止¶