（免责声明：我是与此处链接的博客文章相关组织的员工）
你的问题
我已经在后端设置了检索密码、验证密码并响应令牌的步骤。唯一的问题是，我在前端（移动应用程序）使用的密码被硬编码。
我的问题是：
我应该如何安全地存储这个密码在移动应用程序中，以便黑客无法嗅探出来并用于破坏后端？
残酷的事实是...你不能！！！
看起来你已经对这个问题进行了广泛的研究，而且在我看来，你提到了一种有效的方法，即：
隐藏在本地库中
但正如你所说：
这些方法基本上是无用的，因为黑客可以轻松地规避这些保护方法。
有些方法是无用的，而其他方法则使得逆向工程移动应用程序的秘密变得更加困难。正如我在这里所写的那样，使用本地接口来隐藏秘密的方法需要专业知识才能进行逆向工程，但是如果很难对二进制文件进行逆向工程，您总是可以采用中间人攻击（MitM）来窃取秘密，就像我在这里展示的那样，通过使用本地接口JNI/NDK来检索隐藏在移动应用程序二进制文件中的秘密。
为了保护您的移动应用程序免受MitM攻击，您可以使用证书固定：
Pinning是将主机与其预期的X509证书或公钥相关联的过程。一旦已知或看到了主机的证书或公钥，就会将证书或公钥与主机关联或“固定”。如果有多个证书或公钥可接受，则程序会保留一个Pinset (采用Jon Larimer和Kenny Root Google I/O谈话中的方法)。在这种情况下，广告身份必须与Pinset中的元素之一匹配。
你可以阅读这个系列的React Native文章，学习如何应用证书固定来保护移动应用和API服务器之间的通信渠道。
如果您还不知道，证书固定也可以通过使用Frida或xPosed等工具进行绕过。
Frida是一个强大的工具，它可以将您自己的脚本注入黑盒子进程中。它可以挂钩任何函数、监视加密API或跟踪私有应用程序代码，无需源代码。编辑、保存并立即查看结果，所有这些都不需要编译步骤或程序重启。
xPosed
Xposed是一个框架，用于模块化地改变系统和应用程序的行为，而不需要触及任何APK文件。这很棒，因为它意味着模块可以适用于不同版本甚至ROM，而无需进行任何更改（只要原始代码没有被过度修改）。而且撤销也很容易。
现在你可能会想知道如何防止证书绑定绕过？
嗯，这并不容易，但是通过使用移动应用程序认证解决方案是可能的。
在我们进一步讨论之前，我想首先澄清开发人员之间的一个常见误解，即谁和什么正在访问API服务器。
访问API服务器的“谁”和“什么”的区别
为了更好地理解访问API服务器的谁和什么之间的区别，让我们使用这张图片：
目的沟通渠道指的是使用移动应用程序的合法用户，没有任何恶意意图，使用未被篡改的移动应用程序，并直接与API服务器进行通信。
实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用经过重新打包的移动应用程序，黑客可能在中间攻击时使用真正版本的移动应用程序，以了解移动应用程序与API服务器之间的通信方式，以便能够自动攻击您的API。还有许多其他情况，但我们不会在此枚举每一个情况。
我希望到现在为止，您已经明白了为什么WHO和WHAT不是相同的，但如果没有，一会儿就会清楚。
WHO指的是可以通过多种方式验证、授权和识别的移动应用程序用户，如使用OpenID Connect或OAUTH2流程。
OAUTH
OAuth通常为客户端提供了“安全委托访问”，以代表资源所有者访问服务器资源。它规定了一种过程，使资源所有者能够授权第三方访问其服务器资源，而无需共享其凭据。OAuth专门设计用于与超文本传输协议（HTTP）配合使用，基本上允许授权服务器通过资源所有者的批准向第三方客户端发放访问令牌。然后，第三方使用访问令牌来访问由资源服务器托管的受保护资源。
OpenID Connect
OpenID Connect 1.0是OAuth 2.0协议之上的一个简单身份验证层。它允许客户端根据授权服务器执行的身份验证来验证终端用户的身份，并以可互操作和类似REST的方式获取有关终端用户的基本配置文件信息。
虽然用户身份验证可以让API服务器知道谁正在使用API，但它不能保证请求来自您所期望的何处，即移动应用程序的原始版本。
现在我们需要一种方法来识别调用API服务器的是什么，这比大多数开发人员想象的要困难得多。 是什么是发出对API服务器请求的东西。它真的是移动应用程序的真实实例，还是一个机器人、自动化脚本或攻击者手动使用像Postman这样的工具来探测API服务器？
令人惊讶的是，您可能会发现其中之一是使用重新打包版本的移动应用程序或尝试以游戏化方式利用应用程序提供的服务的自动化脚本。
为了识别是什么，开发人员通常会使用API密钥，并将其硬编码到其移动应用程序代码中。有些开发人员会额外走一步，在移动应用程序中的运行时计算密钥，因此它成为运行时秘密，而不是前一种方法，即在代码中嵌入静态秘密。
以上内容摘自我写的一篇文章，题为《为什么你的移动应用需要 API 密钥？》，您可以在
此处完整阅读，这是一系列关于 API 密钥的文章中的第一篇。
移动应用程序认证
使用移动应用程序认证解决方案将使 API 服务器知道哪个应用程序正在发送请求，从而只响应来自真正移动应用程序的请求，同时拒绝来自不安全来源的所有其他请求。
移动应用程序认证服务的作用是在运行时保证您的移动应用程序未被篡改，未在根设备上运行，并且未成为 MitM 攻击的目标。这是通过在后台运行 SDK 并与在云中运行的服务通信来实现的，以证明移动应用程序和设备的完整性。云服务还验证 TLS 证书是否确实由移动应用程序在与 API 服务器握手时提供，并且与移动应用程序的原始和真实 API 服务器使用的证书相同，而不是来自 MitM 攻击的证书。
在移动应用完整性成功认证后，会发出一个短暂的JWT令牌，并使用只有API服务器和云中的移动应用认证服务知道的密钥进行签名。如果移动应用认证失败，则JWT令牌将使用API服务器不知道的密钥进行签名。
现在，每次API调用时，应用程序必须在请求的标头中发送JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和过期时间并拒绝验证失败时才提供请求。
一旦移动应用认证服务使用的密钥未被移动应用程序知道，即使应用程序被篡改，在根设备上运行或通过成为中间人攻击目标的连接进行通信，也无法在运行时对其进行反向工程。
因此，这种解决方案在正面检测模型中起作用，没有误报，因此不会阻止合法用户，同时将坏人保持在海湾地带。
您有什么建议来保护世界（React-Native应用程序）免受恼人的黑客攻击，当他们窃取密钥并不当使用它们时？
我认为你应该选择一个移动应用程序认证解决方案，如果你有专业知识，可以自己开发，或者你可以使用像我所在的SAAS解决方案一样已经存在的解决方案。集成还需要在API服务器代码中进行小型检查，以验证云服务颁发的JWT令牌。这个检查对于API服务器能够决定哪些请求提供服务和哪些请求拒绝是必要的。
摘要
我想能够在应用程序中存储密钥，以便我可以验证用户并允许他们访问后端资源。然而，我不知道确保用户/企业安全的最佳行动计划是什么。
不要走存储密钥在移动应用程序的路线，因为正如你通过广泛的研究已经知道的那样，它们可以被绕过。
相反，使用移动认证解决方案与OAUTH2或OpenID连接结合使用，你可以将其与移动应用程序认证令牌绑定。关于此令牌绑定的示例可以在this article中找到，用于检查端点/forms中的自定义负载声明。
超越期望
OWASP 移动安全项目 - 前十大风险
OWASP 移动安全项目是一个集中的资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供开发控件以减少其影响或被利用的可能性。
