我想我可以帮助解决您的疑虑。

那么我们想要保护什么？我们正在努力保护自己免受攻击者通过我们的网络服务侵入用户帐户。具体来说，我们如何保护自己免受有足够动机在野外对我们的移动应用程序进行逆向工程的攻击者的攻击？

你不能。就是这么简单。试图做不可能的事情是引起你担忧的原因。相反，在客户端可能是您的应用程序或者它可能是一些未知的恶意客户端的假设下设计和实现您的服务器。如果您无法通过这些假设来保护您的应用程序，那么您将需要购买不安全的应用程序（可能是一个糟糕的错误选择），或者只有在您可以物理控制的位置拥有客户端（也可能是一个错误的选择）。

让我谈谈你的一些具体陈述：

我不得不假设移动银行应用程序已经解决了这个问题。但他们不太可能在这里分享这些知识！

不，这是错误的。我不确定您认为这些神秘的移动银行应用程序开发人员是谁，但我可以向您保证，该网站上的许多人都开发了移动或其他方式的银行应用程序，并帮助保护它们。

我们的攻击者可以通过欺骗我们应用的用户登录网络序列来针对我们运行密码列表。由于我们的攻击者能够在退出应用程序时观察 HTTPS 流量，因此我们的攻击者知道如何构建 Web 服务请求和身份验证。

绝对正确。攻击者可以对您的服务器执行暴力密码攻击。帐户锁定、指数延迟和验证码等技术将有助于防范这种情况。

我们可以在登录（和其他）信息离开应用程序之前对其进行加密。假设我们的攻击者不拥有加密中使用的密钥，这应该可以防止嗅探和欺骗。

鉴于入站（到服务器）流量对保护更重要，公钥加密将成为可能。只有服务器可以解密它。

信任 SSL。它经过了很好的测试并且运行良好。无需使用基于应用程序的加密来防止中间人攻击。我知道连接像 Fiddler 这样的调试代理并以明文形式查看您所谓的加密流量是很奇怪的，但这并不是真正的安全问题。这是用户的数据，如果他们愿意，让他们看看。并且由于服务器的编写概念是它永远无法知道客户端正在运行什么应用程序，因此您的协议应该能够经受住潜在攻击者的检查。请注意，您仍然必须进行适当的 SSL 验证以防止第 3 方 MiTM 攻击。

所以在使用 SSL 时跳过 HMAC 和客户端应用程序加密。相反，编写一个健壮且安全的 API。不是因为我这么说，而是因为别无选择。你自己的分析证明了这一点。

编辑：

防止我们的攻击者使用我们的 Web 服务 API 运行密码列表并可能登录到成员帐户。我们还有其他暴力检测措施，但我们希望直接保护我们的 API 免受此类攻击。

我之前提到过帐户锁定，尽管OWASP 指南似乎不太喜欢它们，因为它们可以在 DOS 中使用。确实提到延迟重复尝试失败的响应。

指南接着说：

尽管蛮力攻击很难完全阻止，但它们很容易被检测到，因为每次失败的登录尝试都会在您的 Web 服务器日志中记录一个 HTTP 401 状态代码。监视您的日志文件是否存在暴力攻击非常重要，尤其是混合的 200 个状态代码，这意味着攻击者找到了有效密码。

虽然没有人希望他们的用户被黑客入侵，但识别并响应成功的密码攻击将大大降低攻击成本。监控还可以让您（暂时）锁定 IP 地址以终止恶意用户（尽管强大的攻击可能来自许多 IP 地址，因此很难做到这一点）。

双重身份验证可减少密码被盗的影响。

防止我们的攻击者使用我们的 Web 服务 API 来探测我们的服务器是否存在其他攻击可能性。

抱歉，如果没有人身安全，您将无法真正做到这一点。您可以在您的应用程序中嵌入秘密、对其进行模糊处理等……但这些都不能真正使应用程序更安全，它只会增加攻击成本，因为这些攻击可以进行反向工程。因此，无论您是否实施这些策略，您仍然必须设计您的 API，就好像攻击者可以访问您的秘密和代码一样。

我是SAST 和 DAST的忠实粉丝。在每次部署之前运行静态分析并解决所有高/关键问题。动态扫描也是如此。漏洞扫描程序还可以检查您的站点是否存在已知漏洞和错误配置。

你的问题仍然没有多大意义。

听起来您正在尝试保护用户帐户免受枚举和暴力破解密码的影响。这与您的客户无关。

要防止暴力密码攻击，请参阅https://stackoverflow.com/questions/30369529/block-request-for-multiple-unsuccessful-logins-for-a-period-of-time/30382110#30382110

为了防止用户名枚举，无论用户名是否存在，都返回相同的“成功”消息以进行注册或密码重置。

请明确指出您要解决的实际问题，而不提供任何潜在的解决方案，我们可以更好地帮助您。

您的攻击者能够嗅探应用程序流量，因为他必须使用某些代理工具，例如 fiddler。这不是您的应用程序的问题。这就是这些代理工具的工作方式。作为应用程序开发人员，您应该知道这一点，并且您应该相应地实施安全控制。如果您想避免这种情况，您可能需要使用证书固定，但这也不是万无一失的。您应该始终假设最坏的情况并开发您的代码。将所有安全控制和业务逻辑放在服务器端，不要在客户端存储任何敏感信息。

证书固定是另一种常用的针对传输中数据攻击的控制措施。如果客户端没有收到位于客户端（移动应用程序）已知 Pin 列表中的公钥，则 TLS 握手永远不会开始。

我使用 Cert Pinning 作为对有效负载加密的补充。也许以下内容正在成为敏感移动应用数据的基本标准？看起来 Tweets 和 Facebook 状态更新使用了所有这三个：

1. 证书固定
2. 有效载荷加密
3. TLS

这些都是可以打败的。但是，我们不是处于层层防御和减缓攻击者的游戏中吗？

您完美地总结了问题；你怎么知道移动应用程序在那里？它可以是 Postman 或 Paw 自动请求之类的工具。如果知道有效载荷加密密钥，那一切都会失败。