流行的应用程序如何验证从移动应用程序到其服务器的用户请求？

Question

流行的应用程序如何验证从移动应用程序到其服务器的用户请求？

Mav*_*ven 109 authentication android facebook foursquare

假设我有一个连接到.Net API的Android应用程序,用于接收/设置数据.我所遇到的困惑是关于如何在每次向API发出请求时第一次注册/登录用户并对其进行身份验证.

如果我只使用基于用户名/密码的身份验证,他们将不够安全？
当然,出于安全原因,我无法在设备中保存该用户名/密码？
我是否应该在注册时为每个用户发出GUID,将其保存在他们的设备中并在API请求期间每次检索？

还有哪些其他模式可用,哪些模式最有效和最安全,我只需要一个流程.有人能告诉我Facebook,FourSquare或Twitter等着名的Android应用程序使用什么方法来验证从他们的移动应用程序到他们的服务器的每个请求？

如果这不是一些公开信息,请提前抱歉.

Answer 1

sim*_*mon 46

我想他们使用的是基于"令牌"的安全系统,因此密码实际上永远不会存储在任何地方,只是在第一次使用时进行身份验证.因此,应用程序最初发布用户名/密码(通过ssl),服务器返回应用程序存储的令牌.对于后续同步尝试,首先发送令牌,服务器检查它是否有效,然后允许发布其他数据.

令牌应该到期,以便服务器可以重新请求身份验证尝试.

如果您从Android Framework中挂钩同步适配器,那么您就可以同时对所有内容进行同步和身份验证.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

如果您检查设备上"设置"下的帐户,您会看到我的意思.

Answer 2

Exa*_*a37 22

如果我只使用基于用户名/密码的身份验证，它们就不够安全吗？

不，因为您只能识别正在访问 API 服务器的WHO，而不是正在访问它的WHAT。

WHO 和 WHAT 访问 API 服务器的区别

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

中间人攻击

预期通信通道表示移动应用程序按照您的预期使用，由没有任何恶意意图的合法用户使用，使用移动应用程序的未篡改版本，并直接与 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 密钥的系列文章中的第一篇。

在客户端设备中存储敏感数据

出于安全原因，我无法将该用户名/密码保存在设备中？我是否应该在注册时为每个用户发布一个 GUID，将其保存在他们的设备中并在每次 API 请求期间检索？

您保存在设备中的任何内容，即使是加密的，都可以在运行时使用 Frida 或 Xposed 等工具进行逆向工程。

弗里达

将您自己的脚本注入黑盒进程。挂钩任何函数，监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，并立即查看结果。无需编译步骤或程序重新启动。

摆姿势

Xposed 是一个模块框架，可以在不接触任何 APK 的情况下更改系统和应用程序的行为。这很棒，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码

在攻击者控制的设备中，他还可以使用代理来执行中间人攻击，以提取可用于识别WHAT或WHO 的任何秘密，正如我在文章中与攻击中的人窃取 API 密钥所示：

虽然我们可以使用 JNI/NDK 等高级技术将 API 密钥隐藏在移动应用程序代码中，但它不会阻止某人执行 MitM 攻击以窃取 API 密钥。事实上，中间人攻击很容易，甚至可以由非开发人员实现。

那么现在怎么办……我是不是注定无法保护我的 API 服务器不被滥用？？？没有安静所以......希望仍然存在！！！

可能的解决方案

有人能告诉我 Facebook、FourSquare 或 Twitter 等著名的 android 应用程序使用什么方法来验证从他们的移动应用程序到他们的服务器的每个请求吗？

抱歉，我对这个应用程序的了解不够，无法向您解释，但我可以为您指出其他一些方法。

还有哪些其他模式可用以及哪些模式最有效和最安全，我只需要一个流程。

因此，任何在客户端运行并需要一些秘密才能访问 API 的东西都可能以不同的方式被滥用，您可以在有关移动 API 安全技术的本系列文章中了解更多信息。本文将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS 固定来保护 API 以及如何绕过它们。

要解决WHAT访问您的移动应用程序的问题，您需要使用我上面提到的有关移动 API 安全技术的系列文章中提到的一个或所有解决方案，并接受它们只会使对您的 API 服务器的未授权访问更难绕过但并非不可能。

使用移动应用证明解决方案可以采用更好的解决方案，该解决方案将使 API 服务器知道仅接收来自真正移动应用的请求。

移动应用认证

使用移动应用证明解决方案将使 API 服务器知道发送请求的是什么，从而允许仅响应来自真正移动应用的请求，同时拒绝来自不安全来源的所有其他请求。

移动应用证明解决方案的作用是在运行时保证您的移动应用没有被篡改，没有在有根设备中运行，没有被 xPosed 或 Frida 之类的框架所检测，没有受到中间人攻击，这是通过在后台运行 SDK 来实现的。在云中运行的服务将挑战应用程序，并根据响应证明移动应用程序和设备运行的完整性，因此 SDK 永远不会对任何决定负责。

成功证明移动应用程序完整性后，将发布一个短期存在的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用程序认证失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。

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

一旦移动应用程序认证服务使用的秘密不被移动应用程序知道，即使应用程序被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程。中间人攻击的目标。

移动应用证明服务已经作为 Approov 的 SAAS 解决方案存在（我在这里工作），它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定提供哪些请求以及拒绝哪些请求是必要的。