通过在移动应用程序中混淆API 或将 API 密钥移动到安全的云服务并在运行时将它们交付给移动应用程序是保护 API 更好的方法吗？
保护 API 密钥是移动应用安全的一个重要方面，保护这些密钥的主要方法有两种：代码混淆和运行时密钥。在本文中，我们将探索这两种方法并比较它们在保护 API 密钥方面的有效性。这两种方法各有利弊，选择取决于具体的用例和安全要求。
代码混淆：
代码混淆是修改应用程序的源代码的过程，使攻击者更难进行逆向工程和提取 API 密钥等敏感信息。这种方法涉及重命名变量、修改控制流结构和插入伪代码以迷惑攻击者。在移动应用程序中混淆 API 密钥可以通过使攻击者更难发现和提取用于访问 API 的 密钥（无论是常规 API 密钥、JWT 令牌或任何其他形式的 密钥）来提供安全保护。
然而，虽然代码混淆是阻止一般攻击者的有效方法，但它并非万无一失。该方法容易受到使用开源工具反向工程移动应用程序二进制文件以查找和提取API密钥的攻击。例如，使用移动安全框架，如文章《如何通过静态二进制分析从移动应用程序中提取API密钥》中提到的，即使是非开发人员也可以提取高价值的密钥。 有经验的攻击者也可以使用逆向工程工具在运行时分析代码并发现更多隐藏的API密钥。最后，代码混淆会给开发过程和底层代码库的持续维护带来直接和间接成本，但不可否认它是一种保护您的代码知识产权 (IP) 的有效方法。
运行时加密：
运行时加密涉及将 API 密钥等敏感信息存储在应用程序代码之外的位置，如配置文件或服务器中。当应用程序需要使用 API 密钥时，它会在运行时从外部位置检索它。将 API 密钥从移动应用程序代码中移除，并将它们重新定位在安全的云服务中，使移动应用程序在需要进行 API 请求时可以随时获取API密钥，可以提供更高级别的安全性。
与代码混淆相比，此方法具有多项优势。首先，API 密钥不存在于应用程序代码中，这使得通过逆向工程提取它们变得更加困难。此外，运行时加密使 API 密钥的轮换更容易，因为每次更改密钥时，应用程序不需要通过 iOS 和 Android 应用程序商店重新编译或重新发布。API 访问也可以限制为真正的（未修改的）实例。移动应用程序和云服务器可以配置为检测和限制从受损的设备、模拟器或框架上运行的应用程序的访问。
但是，运行时加密确实有一些潜在的缺点。其一，外部存储位置必须得到安全保障，否则攻击者可能会获得对 API 密钥的访问权限。此外，在运行时检索密钥可能会带来一些性能开销，并且运行时加密需要为移动应用程序和安全云服务开发额外的软件以提供 API 密钥。运行时加密需要在安全的云服务上部署服务（并进行维护以熟悉最新的安全威胁）。开发此类安全解决方案的专业知识和工作量不小，需要数月的开发时间、数年的完善时间以及大量持续的研究，以跟上零日攻击和新形式攻击的步伐。或者，您可以使用外包安全云服务并使用相同的方法。
更多相关信息，请参阅文章《移动应用和API安全实战 - 运行时机密保护》。
方法比较：
在运行时加密或代码混淆二选一时，必须考虑被破坏的成本及其对业务和声誉的短期和长期影响。传统上，数据泄露的成本，如罚款、声誉、客户流失和利润下降，远大于对适当安全解决方案的投资。所有这些都必须考虑到，以及遭到攻击的可能性。
那么，哪种方法更适合保护 API 密钥？最终，这取决于应用程序的具体需求和限制。对于不处理高度敏感信息且不太可能成为坚定的攻击者目标的应用程序，代码混淆可能是一个合理的选择。但是，对于需要保护敏感数据或可能成为攻击目标的应用程序，运行时加密可提供更稳健和安全的解决方案。
结论：
首先值得注意的是，这两种方法并不是相互排斥的。事实上，许多移动应用程序同时使用代码混淆和运行时加密来保护应用程序内的知识产权以及授予访问云中有价值数据的 API 密钥。通过组合这些方法，开发人员可以针对攻击者创建更稳健和分层的深度防御。
保护 API 密钥对于确保移动应用程序的安全至关重要。总之，如果安全是重中之重，并且可以接受额外的基础设施，则将 API 密钥移至安全的云服务，并在运行时将它们交付给移动应用程序是更安全的选择。虽然代码混淆可能是阻止偶发攻击的合理方法，但运行时加密提供了一种更强大、更安全的解决方案来保护敏感数据。最终，最佳方法将取决于应用程序的具体需求和限制。通过仔细考虑选项并实施分层防御策略，开发人员可以帮助确保其移动应用程序的安全性。
总之，当您想要保护和捍卫代码本身的知识产权时，代码混淆总是非常适合，但是对于通过 API 访问并在云服务中保存的价值数据，代码混淆则不太适用。为了保护通过渠道共享并受 API 密钥保护的有价值数据，最好的方法是从移动应用程序中删除硬编码的秘密，并利用安全云服务提供的运行时加密。