React Native中最安全的密钥存储方式是什么

Question

感谢您的帮助。

我正在使用React Native和Node.js为我的公司交付产品。

我已经在后端设置了步骤来检索密码，对其进行验证并使用令牌进行响应。唯一的问题是-我在前端（移动应用程序）上使用的要由后端验证的密码是硬编码的。

我的问题是：

我应该如何安全地将该密码存储在移动应用程序上，以使它不会被黑客嗅出并用于破坏后端？

到目前为止，我的研究。

嵌入在strings.xml中

隐藏在源代码中

隐藏在BuildConfigs中

使用Proguard

伪装/加密的字符串

隐藏在本地库中

http://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/

这些方法基本上没有用，因为黑客可以轻松绕开这些保护方法。

https://github.com/oblador/react-native-keychain

尽管这可能会混淆密钥，但仍必须对其进行硬编码。除非我错过了一些东西，否则这些都将变得无用。

我可以使用.env文件 https://github.com/luggit/react-native-config

再次，我觉得黑客仍然可以查看秘密密钥，即使它们已保存在.env中。

我希望能够在应用程序中存储密钥，以便可以验证用户并允许他们访问后端的资源。但是，我不知道最好的行动计划是确保用户/企业安全。

当讨厌的黑客窃取密钥并不恰当地使用它们时，您有什么建议可以保护整个世界（真实的应用程序）免受攻击？

Answer 1

你的问题

我已经在后端设置了步骤来检索密码，对其进行验证并使用令牌进行响应。唯一的问题是-我在前端（移动应用程序）上使用的要由后端验证的密码是硬编码的。

我的问题是：

我应该如何安全地将该密码存储在移动应用程序上，以使它不会被黑客嗅出并用于破坏后端？

残酷的事实是……你不能！！！

看来您已经对该主题进行了广泛的研究，并且我认为您提到了一种将应用程序与嵌入式机密一起发布的有效方法：

隐藏在本地库中

但是正如您还说的那样：

这些方法基本上没有用，因为黑客可以轻松绕开这些保护方法。

有些是无用的，而另一些则使反向工程更难从移动应用程序中获得秘密。就像我在这里写的那样，使用本机接口隐藏秘密的方法将需要专业知识来对它进行逆向工程，但是如果很难对二进制文件进行逆向工程，则您总是可以诉诸于中间人（MitM）攻击钢铁这个秘密，正如我在此处显示的，通过使用本机接口JNI / NDK检索隐藏在移动应用程序二进制文件中的秘密。

为了保护您的移动应用不受MitM的侵害，您可以使用证书固定：

固定是将主机与其预期的X509证书或公钥相关联的过程。一旦知道或看到了主机的证书或公钥，便会将证书或公钥关联或“固定”到主机。如果可以接受多个证书或公钥，则该程序将保留一个密码集（取自Jon Larimer和Kenny Root Google I / O谈话）。在这种情况下，广告身份必须与引脚集中的元素之一匹配。

您可以阅读这一系列的本机React文章，向您展示如何应用证书固定来保护移动应用程序与API服务器之间的通信通道。

如果您还不知道，还可以使用Frida或xPosed之类的工具绕过证书固定。

弗里达

将自己的脚本注入黑匣子进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。

x位置

Xposed是一个模块框架，可以在不影响任何APK的情况下更改系统和应用程序的行为。太好了，因为这意味着模块可以用于不同版本甚至ROM，而无需进行任何更改（只要原始代码的更改不太多）。撤消也很容易。

因此，现在您可能想知道如何保护我免受证书钉扎绕过？

通过使用移动应用证明解决方案，好起来并不容易，但有可能实现。

我们进一步去之前，我想先澄清开发商中一种常见的误解，关于WHO和WHAT访问API服务器。

WHO与访问API服务器之间的区别

为了更好地了解WHO和WHAT访问API服务器之间的区别，让我们使用以下图片：

预期的通信渠道表示合法用户在没有任何恶意意图的情况下正按预期使用该移动应用程序，使用该移动应用程序的未更改版本，并直接与API服务器通信，而不会受到中间人的攻击。

实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本，黑客使用了移动应用程序的真实版本，而中间人则在攻击它，以了解如何移动应用程序与API服务器之间的通信已完成，以便能够自动对您的API进行攻击。其他许多情况也是可能的，但在此我们将不逐一列举。

我希望到现在为止您可能已经有了线索，为什么WHO和WHAT并不相同，但是如果不是这样，那一会儿就会明白。

该世界卫生组织是移动应用程序，我们可以验证，授权和以多种方式确定，比如使用OpenID登录连接或流的oauth2的用户。

绿洲

通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一个在不共享凭据的情况下授权第三方访问其服务器资源的过程。OAuth专为与超文本传输​​协议（HTTP）配合使用而设计，本质上允许访问令牌由授权服务器在资源所有者的批准下发布给第三方客户端。然后，第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID连接

OpenID Connect 1.0是基于OAuth 2.0协议的简单身份层。它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终​​用户的基本配置文件信息。

虽然用户认证可以让API服务器知道世卫组织正在使用的API，它不能保证请求源自什么你期望的那样，移动应用程序的原始版本。

现在，我们需要一种方法来确定什么是调用API服务器，这里的事情变得比大多数开发人员可能会觉得更靠谱。在什么是发出请求到服务器API的东西。它是否真的是移动应用程序的真正实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者？

令您惊讶的是，您可能最终发现，它可能是使用重新打包的移动应用程序版本或尝试进行游戏化并利用该应用程序提供的服务的自动脚本的合法用户之一。

好了，要确定WHAT，开发人员通常会使用通常在其移动应用程序代码中进行硬编码的API密钥。一些开发人员付出了更多的努力，并在移动应用程序中在运行时计算了密钥，因此与将静态机密嵌入代码中的前一种方法相反，它成为了运行时机密。

以上文章摘自我写的一篇文章，标题为《为什么您的移动应用程序需要API密钥？，您可以在此处完整阅读，这是有关API密钥的系列文章中的第一篇。

行动应用程式证明

使用移动应用程序认证解决方案将使API服务器就知道什么是发送请求，因此允许而拒绝来自不安全来源的所有其他请求从一个真正的移动应用程序只响应请求。

移动应用程序证明服务的作用是确保在运行时您的移动应用程序未被篡改，不在有根设备中运行并且不成为MitM攻击的目标。这是通过在后台运行SDK来完成的，该SDK将与在云中运行的服务进行通信以证明移动应用程序和设备正在运行的完整性。云服务还验证与API服务器握手时提供给移动应用程序的TLS证书是否确实与移动应用程序的原始和真正的API服务器使用的相同，而不是来自MitM攻击的一个。

在成功证明移动应用程序完整性后，将发布并签名一个短时生存的JWT令牌，并秘密告知只有云服务器中的API服务器和移动应用程序证明服务。在移动应用证明失败的情况下，将使用API​​服务器不知道的秘密对JWT令牌进行签名。

现在，应用程序必须与每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝请求。

一旦移动应用程序不知道移动应用程序证明服务使用的机密，就无法在运行时对其进行反向工程，即使该应用程序被篡改，在有根设备中运行或通过正在作为连接的连接进行通信中间攻击中一名男子的目标。

因此，此解决方案可在没有误报的积极检测模型中工作，因此不会阻止合法用户，同时又阻止了坏人。

当讨厌的黑客窃取密钥并不恰当地使用它们时，您有什么建议可以保护整个世界（真实的应用程序）免受攻击？

我认为您应该选择使用移动应用程序认证解决方案，如果您有专业知识，可以自己滚动使用它，或者可以使用Approov上已经作为SAAS解决方案存在的解决方案（我在这里工作），提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。API服务器必须能够执行此检查，才能决定服务哪些请求以及拒绝哪些请求。

摘要

我希望能够在应用程序中存储密钥，以便可以验证用户并允许他们访问后端的资源。但是，我不知道最好的行动计划是确保用户/企业安全。

不要沿着将密钥存储在移动应用程序中的路线走下去，因为众所周知，通过广泛的研究，可以绕过它们。

而是将移动证明解决方案与OAUTH2或OpenID connect结合使用，您可以将其与移动应用证明令牌绑定。在本文中可以找到此令牌绑定的示例，用于检查端点中的自定义有效负载声明/forms。

多走一英里

OWASP移动安全项目-十大风险

OWASP移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制措施，以减少其影响或利用可能性。