我正在开发Android翻译应用程序。应用使用 Azure 认知服务文本转换 API 密钥。
API 密钥位于 Java 文件中的应用程序源代码中，如果我发布应用程序，人们可以破解应用程序 apk 文件并使用我的 API 密钥，这将非常昂贵。有没有办法保护我的API密钥不被盗？应用程序中没有登录，没有登录，任何人都可以从Play商店下载。
如何保护 API 密钥不被盗？
您可以使用 android 密钥库，它适用于像您的官方文档这样的场景
或者可以参考此处的示例代码
逆向工程
API 密钥位于 Java 文件中的应用程序源代码中，如果我发布应用程序，人们可以破解应用程序 apk 文件并使用我的 API 密钥
是的，当存在许多不同的开源以使这项任务易于实现时，即使对于非技术人员也是如此，就像我在文章中使用移动安全框架演示的那样，这并不难做到。 如何使用静态二进制分析从移动应用程序中提取 API 密钥：
可用于逆向工程的开源工具的范围是巨大的，在本文中我们真的无法触及这个主题的表面，而是我们将专注于使用移动安全框架(MobSF)来演示如何对我们移动应用程序的APK进行逆向工程。 MobSF是开源工具的集合，它们在一个有吸引力的仪表板中呈现它们的结果， 但是在MobSF和其他地方使用的相同工具可以单独使用以达到相同的结果。
另外，您可以使用 MobSF 上传目录中的grep命令来查找 MobSF 无法找到的其他机密：
grep -irl '_key"' --include 'strings.xml' --include "AndroidManifest.xml"
和
grep -irn '_key' --include '*.java' --include "*.smali" ./java_source/tld/domain ./smali_source/tld/domain
将_key替换为您可能想要查找的任何其他模式。
将tld/domain替换为正在逆向工程的移动应用程序使用的那个，例如：com/example。
隐藏在本机 C 代码中的秘密
机密可以隐藏在本机 C 代码中，如上述链接文章的演示所示：
在本文中，我们将使用 Android 隐藏秘密研究存储库，这是一个虚拟移动应用程序，使用几种不同的技术隐藏了 API 密钥。
但是，如果你通过静态分析找不到它，那么你就会进行 MitM 攻击，正如我在另一篇文章中演示的那样 窃取 API 键与中间人攻击：
为了帮助演示如何窃取API密钥，我在Github中构建并发布了适用于Android的货币转换器演示应用程序，该应用程序使用与我们在早期Android Hide Secrets应用程序中使用的相同的JNI/NDK技术来隐藏API密钥。
因此，在本文中，您将学习如何设置和运行 MitM 攻击以拦截您控制下的移动设备中的 https 流量，以便您可以窃取 API 密钥。最后，您将在高层次上了解如何缓解 MitM 攻击。
硬件密钥库或保管库中的机密
MitM 攻击的替代方法是使用检测框架在运行时挂接到检索密钥的代码，无论是从 Android 硬件烘焙密钥库还是从您选择的云提供商提供的任何其他保管库：
弗里达：
将您自己的脚本注入黑盒进程。挂接任何函数，监视加密API或跟踪私有应用程序代码，无需源代码。编辑，点击保存，并立即看到结果。所有这些都无需编译步骤或程序重新启动。
第三方服务
API 密钥位于 Java 文件中的应用程序源代码中，如果我发布应用程序，人们可以破解应用程序 apk 文件并使用我的 API 密钥，这将非常昂贵。
是的，它可能非常昂贵，只有当账单已经很大时，您才会发现它，尽管您可以设置计费警报，但它们并不像您想象的那样工作。
反向代理救援
有没有办法保护我的API密钥不被盗？
最佳实践不建议直接从移动应用程序中使用第三方服务，而是应将它们委托给移动应用程序的 API 后端或反向代理，正如我在另一篇文章使用反向代理保护第三方 API 中所写的那样：
在本文中，您将首先了解什么是第三方 API，以及为什么您不应该直接从移动应用程序中访问它们。接下来，您将了解什么是反向代理，然后是何时以及为什么应该使用它来保护对移动应用程序中使用的第三方 API 的访问。
所以，到目前为止，你可能认为你只是从保护访问翻译API的秘密转向访问反向代理或API后端的秘密，你是对的，但有很大的不同，这使得所有的不同，你控制反向代理和/或API后端， 因此，您可以密切监视流量，限制/关闭流量，并根据需要应用尽可能多的安全防御措施以控制事情。
开放接口
应用程序中没有登录，没有登录，任何人都可以从Play商店下载。
因此，您创造了无摩擦的用户体验，但也为自己创造了一个需要解决的安全噩梦。
在我深入研究更多细节之前，重要的是要首先澄清一些关于谁与什么在访问后端之间区别的误解。
WHO和WHAT访问API服务器之间的区别
我写了一系列关于API和移动安全的文章，在文章为什么你的移动应用程序需要API密钥？ 您可以详细阅读访问您的API服务器的人员和内容之间的区别，但我将在这里提取主要内容：
向API 服务器发出请求的事物是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用邮递员等工具手动在您的 API 服务器周围戳来戳去？
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和识别，例如使用OpenID Connect或OAUTH2流。
您可以考虑谁作为您的API 后端或反向代理可以进行身份验证和授权访问数据的用户(如果您正在使用它)，并考虑代表用户发出该请求的软件。
在开放的 API 中，您无法识别请求中的人员，但即使您能够识别，也不足以使用 API 后端或反向代理锁定移动应用程序。
因此，您需要加强将第三方服务委派到您自己的后端或反向代理的是找到一种使用移动应用程序锁定它们的方法。
可能的附加解决方案
有没有办法保护我的API密钥不被盗？
移动应用程序和 API 后端和/或反向代理可以通过引入移动应用程序证明概念来锁定它们，以便它们只接受来自移动应用程序的真实且未篡改版本的请求，从而紧密结合在一起，我建议您阅读我对问题如何保护移动应用程序的 API REST 的答案？特别是强化和屏蔽移动应用程序、保护 API 服务器和可能的更好解决方案部分，以了解更多防御技术并了解移动应用程序证明。
简而言之，移动应用证明解决方案将允许任何后端以非常高的置信度断言请求确实来自您所期望的，即移动应用程序的真实且未篡改的版本，即不是来自机器人、脚本、cURL 或任何其他工具。
你想加倍努力吗？
在对安全问题的任何回答中，我总是喜欢引用OWASP基金会的出色工作。
对于 API
OWASP API 安全性前 10 名
OWASP API安全项目旨在通过强调不安全API中的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了促进实现这一目标，OWASP API安全项目将创建和维护十大API安全风险文档，以及创建或评估API时最佳实践的文档门户。
对于移动应用
OWASP 移动安全项目 - 十大风险
OWASP移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供开发控制，以减少其影响或被利用的可能性。
OWASP - 移动安全测试指南：
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
使密钥难以进行逆向工程的另一种方法是将它们作为本机代码保存在 NDK 中。
另一种解决方案是创建您自己的服务代理，这是您的 REST 服务，它接受用户请求，从 AWS 获取翻译响应，并将响应发送回移动设备。
美妙之处在于密钥不会存储在移动设备上，而缺点是您的 REST 服务成为单点故障，因此您可能需要配置冗余服务器。
但是，由于您的服务是轻量级的，因此它应该可以很好地扩展。