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

Question

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

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

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

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

Answer 1

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

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

如果您从Android Framework中挂钩同步适配器，那么您就可以同步和验证所有内容。

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

如果您在设备的“设置”下查看帐户，则会看到我的意思。

Answer 2

基本上这些着名的使用OAuth协议（1）/框架（2）。即使它必须是标准，但每个都具有此协议/框架的不同实现。因此，在集成方面我们必须非常小心。

示例：Dropbox仍然使用OAuth 1，最近提供了OAuth 2支持。

回到答案，正如peterpan所说，它是一种基于令牌的认证方式，是一次性的事情，并且不在等式中。这些令牌已经过期，或者在某些情况下给予开发人员权力。

这背后的有趣之处在于，可以定义资源访问范围，而不是允许客户端应用程序保留用户名，密码是危险的。

这是其工作原理的基本说明。

我会在得到更多详细信息后更新答案，因为这些天我在这个领域工作：）

Answer 3

我正在寻找完全相同的东西，并找到谷歌的方式，像peterpan说，但通过谷歌API。试试这个链接和谷歌你的方式，我也开始了！我会在发布新信息的时候发布新信息！

http://developer.android.com/google/auth/http-auth.html

Answer 4

我是新手，但我会尝试为给定的问题提供合理的解决方案。

将有两种选择， [1]对于每个URI，将执行http认证，其中将验证用户输入的凭证，并且用户将访问资源。

[2]另一种方法可能是，用户应该进行身份验证，并且在每次身份验证时都会生成一个唯一的令牌。使用生成的令牌，用户应访问资源。

虽然我不确定哪种方法最适合移动应用。

Answer 5

Authentication example是个好地方。 Android在帐户管理器中存储凭据，您可以在Android的设置中查看帐户。这将自动存储令牌，如果过期或丢失，则提示用户输入凭据，刷新令牌等。我发现此示例的http部分缺少或旧。扩展android的AccountAuthenticatorActivity是一个很好的帮助，可以将序列化数据解析到布局并返回到互联网。

Answer 6

  

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

否，因为您只是在确定 WHO 正在访问API服务器，而不是 What 正在访问它。

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

为了更好地了解 WHO 和 What 在访问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服务器知道 WHO 正在使用API​​，但不能保证请求源自您期望的 What 。移动应用。

现在，我们需要一种方法来识别正在调用的API服务器，这使得事情变得比大多数开发人员想象的要棘手。 内容是向API服务器发出请求的内容。它是移动应用程序的真正实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者？

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

好吧，为了确定内容，开发人员倾向于求助于通常会在其移动应用程序代码中进行硬编码的API密钥。一些开发人员花了很多功夫，并在移动应用程序中在运行时计算密钥，因此与将静态机密嵌入代码中的前一种方法相反，它成为了运行时机密。

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

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

  

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

您保存在设备中的所有内容（即使已加密）也可以在运行时使用Frida或Xposed等工具进行反向工程。

Frida

  

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

xPosed

  

Xposed是用于模块的框架，可以在不触摸任何APK的情况下更改系统和应用程序的行为。太好了，因为这意味着模块可以在不进行任何更改的情况下适用于不同版本甚至ROM（只要原始代码

在设备中，攻击者控制着他还可以使用代理来执行中间人攻击，以提取可用于识别 What 或 WHO 如我在文章Steal that API Key with a Man in the Attack中所示：

  

尽管我们可以使用高级技术（例如JNI / NDK）将API密钥隐藏在移动应用程序代码中，但它不会阻止某人执行MitM攻击以窃取API密钥。实际上，MitM攻击很容易被非开发人员实现。

那么，现在...我注定要保护我的API服务器不被滥用吗？？没有安静，所以...希望仍然存在！

可能的解决方案

  

有人可以告诉我，著名的android应用程序（例如Facebook，FourSquare或Twitter）使用什么方法来验证从移动应用程序到服务器的每个请求？

抱歉，但是我对此应用程序的了解不足，无法阐明您的观点，但是我可以为您指出其他一些方法。

  

还有哪些可用的模式，哪些模式最有效，最安全，我只需要一个流程即可。

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

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

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

移动应用证明

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

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

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

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

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

移动应用证明服务已经作为Approov的SAAS解决方案存在（我在这里工作），该服务为多个平台（包括iOS，Android，React Native等）提供SDK。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。

结论

最后，必须根据要保护的内容的价值以及此类数据的法律要求（例如欧洲的GDPR法规）来选择用于保护API服务器的解决方案。

您想参加额外的战斗吗？

OWASP Mobile Security Project - Top 10 risks

  

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

Answer 7

放入SharedPreferences.时，用户名和密码可以是安全的 在连接服务器时使用https也应该足够好。