node.js - 在 React Native 中存储 key 最安全的方式是什么

Question

提前感谢您的帮助。

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

我已经在后端设置了检索密码、验证密码并使用 token 响应的步骤。唯一的问题是 - 我在前端(移动应用程序)上使用的要由后端验证的密码是硬编码的。

我的问题是:

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

我的研究到目前为止。

嵌入在 strings.xml 中

隐藏在源代码中

隐藏在 BuildConfig 中

使用混淆器

伪装/加密字符串

隐藏在本 map 书馆中

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

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

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

尽管这可能会混淆 key ，但它们仍然必须进行硬编码。使这些无用，除非我遗漏了什么。

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

同样，我觉得黑客仍然可以查看 key ，即使它们保存在 .env 中。

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

当讨厌的黑客窃取 key 并不当使用它们时，您有什么建议来保护世界(react-native 应用程序)？

Answer 1

你的问题

I've setup the steps on the backend to retrieve a password, validate it and respond with a token. The only problem is - the password I use on the front end (mobile app) to be validated by the back end is hardcoded.

My question is:

How should I securely store this password on the mobile app so that it can not be sniffed out by a hacker and used to compromise the backend?

残酷的事实是……你不能!!!
似乎您已经对该主题进行了一些广泛的研究，在我看来，您提到了一种使用嵌入式 secret 传送应用程序的有效方法:

Hidden in Native Libraries

但正如你所说:

These methods are basically useless because hackers can easily circumnavigate these methods of protection.

有些是无用的，有些则使从移动应用程序中逆向工程的 secret 变得更加困难。正如我写的 here ，使用 native 接口(interface)隐藏 secret 的方法需要专业知识来对其进行逆向工程，但是如果很难对二进制文件进行逆向工程，您可以随时求助于中间人 (MitM) 攻击来巩固 secret ，如我显示 here用于使用 native 接口(interface)检索隐藏在移动应用程序二进制文件中的 secret ， JNI/NDK .
为了保护您的移动应用程序免受中间人攻击，您可以使用 Certificate Pinning :

Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.

您可以阅读 this series的 native 文章，向您展示如何应用证书锁定来保护您的移动应用程序和 API 服务器之间的通信 channel 。
如果您还不知道证书固定，也可以使用 Frida 或 xPosed 等工具绕过。
Frida

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

xPosed

Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.

所以现在您可能想知道如何防止证书锁定绕过？
这并不容易，但可以通过使用移动应用证明解决方案来实现。
在我们进一步讨论之前，我想首先澄清开发者之间的一个普遍误解，关于 世界卫生组织 和 什么 正在访问 API 服务器。
WHO 和 WHAT 访问 API 服务器的区别
为了更好地了解 之间的差异世界卫生组织 和 什么 正在访问 API 服务器，让我们使用这张图片:

预期通信 channel 表示移动应用程序按照您的预期使用，由没有任何恶意意图的合法用户使用，使用移动应用程序的未篡改版本，直接与 API 服务器通信，而不会受到中间人的攻击。
实际 channel 可能代表几种不同的场景，例如合法用户可能正在使用重新打包的移动应用程序版本，黑客使用正版移动应用程序，而中间人对其进行攻击，以了解如何正在完成移动应用程序和 API 服务器之间的通信，以便能够自动攻击您的 API。许多其他场景也是可能的，但我们不会在此一一列举。
我希望现在您可能已经知道为什么 世界卫生组织 和 什么 不一样，但如果不一样，一会儿就会清楚。
世界卫生组织 是移动应用程序的用户，我们可以通过多种方式对其进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

OAUTH

Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

OpenID Connect

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

虽然用户身份验证可能会让 API 服务器知道 世界卫生组织 正在使用 API，不能保证请求来自 什么 您期望，移动应用程序的原始版本。
现在我们需要一种方法来识别 什么 正在调用 API 服务器，这里的事情变得比大多数开发人员想象的更棘手。 什么 是向 API 服务器发出请求的东西。它真的是移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 之类的工具手动浏览 API 服务器？
令您惊讶的是，您最终可能会发现它可能是使用重新打包的移动应用程序版本或试图游戏化并利用应用程序提供的服务的自动化脚本的合法用户之一。
好了，识别 什么 ，开发人员倾向于求助于通常在其移动应用程序代码中硬编码的 API key 。一些开发人员加倍努力并在移动应用程序中在运行时计算 key ，因此它成为运行时 secret ，而不是在代码中嵌入静态 secret 时的前一种方法。
以上文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API key ？，您可以阅读全文 here ，这是关于 API key 的系列文章中的第一篇。
移动应用认证
使用移动应用证明解决方案将使 API 服务器知道 什么 正在发送请求，因此只允许响应来自真正移动应用程序的请求，同时拒绝来自不安全来源的所有其他请求。
移动应用证明服务的作用是在运行时保证您的移动应用没有被篡改，没有在 Root设备中运行，也没有成为中间人攻击的目标。这是通过在后台运行 SDK 来完成的，该 SDK 将与在云中运行的服务进行通信，以证明正在运行的移动应用程序和设备的完整性。云服务还验证在与 API 服务器握手时提供给移动应用程序的 TLS 证书确实与用于移动应用程序的原始和正版 API 服务器相同，而不是来自中间人攻击的证书。
成功证明移动应用程序完整性后，将发布一个短期存在的 JWT token ，并使用只有 API 服务器和云中的移动应用程序证明服务知道的 secret 进行签名。如果移动应用认证失败，JWT token 会使用 API 服务器不知道的 secret 进行签名。
现在，应用程序必须随每个 API 调用发送请求 header 中的 JWT token 。这将允许 API 服务器仅在可以验证 JWT token 中的签名和到期时间时才提供请求，并在验证失败时拒绝它们。
一旦移动应用程序认证服务使用的 secret 不被移动应用程序知道，即使应用程序被篡改、在 Root设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程。中间人攻击的目标。
因此，该解决方案在没有误报的积极检测模型中工作，因此不会阻止合法用户同时阻止坏人。

What suggestions do you have to protect the world (react- native apps) from pesky hackers, when they're stealing keys and using them inappropriately?

我认为您应该使用移动应用证明解决方案，如果您拥有相关专业知识，您可以自己推出该解决方案，或者您可以使用已作为 SAAS 解决方案存在的解决方案 Approov (我在这里工作)，它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务发布的 JWT token 。此检查对于 API 服务器能够决定提供哪些请求以及拒绝哪些请求是必要的。
概括

I want to be able to store keys in the app so that I can validate the user an allow them to access resources on the backend. However, I don't know what the best plan of action is to ensure user/business security.

不要走这条在移动应用程序中存储 key 的路线，因为您已经知道，通过广泛的研究，它们可以被绕过。
而是将移动证明解决方案与 OAUTH2 或 OpenID 连接结合使用，您可以将其与移动应用证明 token 绑定(bind)。可以在 this article 中找到此 token 绑定(bind)的示例。用于检查端点中的自定义负载声明 /forms .
走得更远
OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.