API密码糟糕！更新你的安全措施

近年来，您可能听说过一些有关无密码身份验证的讨论——十多年来，科技行业领导者一直游说将其作为消费者网络应用程序的 标准做法。

即使无密码身份验证的概念对你来说很新，在 2023 年从事科技行业的人也很难不知道 LastPass 遭受的网络攻击。对于许多人，无论是科技行业的专业人士还是普通消费者，这都是一个警钟。这不仅是一次大规模的数据泄露——超过 3000 万用户的密码被泄露——而且最初是由密码盗窃造成的。

如果连密码管理器都无法安全地管理登录凭据，那么对我们其他人来说意味着什么？也许现在正是无密码身份验证成为焦点的最佳时机。

从消费者的角度来看，现在绝对是采取措施实施更安全的密码管理措施的时候了。 

应用程序开发人员显然有必要改变其身份验证模型。基于浏览器的无密码身份验证比以往任何时候都更加简单，消费者也已准备好为其最敏感的在线活动采用更好的安全实践。

但是 API 团队呢？基于浏览器的身份验证实践不会彻底改变在数据层工作和生活的团队的实践，但对于 API 开发人员和产品经理来说，仍然有一些重要的收获。 

为人类的不完美留出空间

这听起来像是来自治疗师的建议，但任何对网络安全感兴趣的人都需要注意这个警告：人们会犯错，你无法阻止他们——但你可以改变你的环境，让错误造成的危害更小。 

不过，我们并不是要责怪用户！产品团队应该：

• 假设你的用户是会犯错的人类 — — 因为他们确实是！
• 设计可消除错误机会的系统。
• 保护资源，以使错误的影响降到最低。

安全设计，无论是面向消费者的应用程序、面向开发人员的 API 还是介于两者之间的任何应用程序，都必须将安全负担从个人用户身上转移开。OWASP十大安全问题备受关注，但规划网络安全的人为因素比检查该列表中的任何项目都更为重要。至少 80% 的网络攻击涉及人为错误。是的，遵循 OWASP 原则将有助于您避免这些错误 – 这些原则的存在是为了服务于创建和使用技术产品的人们。 

有意使用密码和 API 密钥

密码特别容易受到人为错误的影响，因为从安全因素的角度来看，它们是“你知道的东西”。API 密钥也类似——这是否意味着我们也应该摆脱它们？幸运的是，答案是否定的。

我们不太可能完全取代密码。使用加密密钥或 MFA 来保护您的 wifi 将是毫无意义的麻烦——它是一个低价值目标，需要由多个人和设备访问，并且当它同时扩展到太多用户时最容易受到攻击。密码完全没问题。

API 密钥也有适当的用途。考虑一个免费的天气数据 API。API 密钥对于速率限制和使用指标最为重要，而更繁重的身份验证方法则不会带来回报。它与 Wi-Fi 网络有类似的约束 – 未经授权访问的缺点非常低，提供易于访问很重要，而最重要的风险来自流量激增或 DDOS攻击。如果这描述了您的 API，请随意使用速率限制密钥！

但是，一旦涉及任何专有数据或财务信息，就必须开始询问有关安全设计的问题。API 消费者首先如何访问他们的密钥？它是否受到基于密码的身份验证方法的保护？API 密钥是否与任何财务数据或个人身份信息相关？任何敏感数据是否保存在托管公共端点的同一台服务器上？依靠 API 消费者适当地管理这些风险并不理想。

旨在通过设计实现安全

安全“左移”的势头正在强劲。在许多情况下，这意味着转向“ DevSecOps”模式，从开发生命周期一开始就将安全性集成到自动化流程中。这是一种实际的转变，也是一种文化的转变——安全性不是事后的想法或障碍，而是每个阶段不可或缺的考虑因素。如果做得正确，DevSecOps 会更安全、更高效。

当 DevSecOps 方法导致开发团队将安全性视为主要运营问题时，这种方法可能会失败。运营问题很重要，我们将在下文中进一步讨论这些问题 – 但任务应该是从设计上保证安全性。这意味着在设计产品和流程的每个方面时都要考虑到安全性。

安全性设计与以人为本的设计密不可分。无论您是在查看数据层的架构、如何在代码 linter 中实施安全实践，还是对不同资源使用哪些身份验证协议，目标都是限制人为错误的可能性，并在有人不可避免地犯错时将损害降至最低。 

警惕中间人！

窃取密码和其他敏感数据的最常见手段之一是“中间人”攻击。在这一领域，应用程序开发人员开始意识到大多数 API 开发人员已经知道的事实：加密至关重要！ 

API 最成功的地方：TLS

至少，在 2023 年，任何人都不应该通过不安全的 HTTP 连接传输任何数据。到目前为止，HTTPS For Everything已成定局。大多数 API 通信可能应该通过某种额外的加密来保护。在大多数情况下，TLS是一个不错的选择。 

WebAuthn 是业界最佳的无密码身份验证浏览器标准，它使用与 TLS 相同的加密方法：

• 通过公钥/私钥对进行初始身份验证，称为非对称加密。 
• 对会话期间传输的所有数据进行对称加密。

WebAuthn与多因素身份验证不同，需要注意的是，MFA/2FA 方法失宠的部分原因是缺乏加密。短信是许多 MFA 流程中的流行选项，但它无法加密，而且很容易被拦截，因为蜂窝网络的设计并不安全。 

您仍然可以使用智能手机作为 WebAuthn 流程的一部分。在任何具有认证身份验证器的设备上，您都可以生成公钥/私钥对并将其注册到应用程序或服务中。私钥永远不会离开设备，使用公钥加密的数据只能由私钥解密，反之亦然。相关数据以JSON 对象的形式传输。

API 有时会出错的地方：JWT

如果您是一名 API 开发人员，这听起来很熟悉，可能是因为您以前使用过JWT。WebAuthn的大部分数据流与 JWT 身份验证类似。JWT并不完美，WebAuthn 和 JWT 之间的差异说明了原因。 

JWT 的一个风险来源是，在预设的过期时间之前，很难撤销令牌。在令牌有效期间，客户端应用程序控制会话。即使客户端开始执行可疑或恶意操作，服务器也无法终止单个令牌。这使得 JWT不适合基于会话的身份验证，尽管这是一种常见做法。相比之下，WebAuthn 允许客户端和服务器应用程序随时终止身份验证。客户端应用程序从不直接处理密钥，但必须具有加密的有效证明才能完成任何请求。通过撤销公钥，服务器可以随时 强制进行新的注册。

值得强调的第二个区别是加密。在 WebAuthn 应用程序中，除注册仪式期间的公钥外，所有流量都经过加密。可以加密JWT 身份验证流程中的所有通信，但此行为不是默认行为。除非您选择使用JSON Web 加密(JWE)，否则 JSON 令牌是签名的但未加密。签名可保护消息免遭篡改，但不能防止通过中间人攻击进行拦截。 

虽然这些选项本身都不是坏的（也许除了 SMS 2FA），但 API 团队需要注意加密的内容和时间。对所有请求使用完全非对称加密是有成本的，但在某些情况下，这是值得投资的。在金融和医疗保健领域，监管指南会告诉您何时需要传输加密或静态加密。但即使在监管较少的行业，您也需要小心选择能够妥善保护数据的身份验证和加密协议。

将前端应用程序视为顶级安全问题

优秀 API 产品最有价值的属性之一是它与客户端无关。如果您正在构建 API，您无疑会考虑一些特定的用例，但 API 使用者会做一些您从未预料到的事情，而且通常会带来令人印象深刻的结果。虽然这种创造力可能会导致一些问题，但对于 API 产品团队来说，重要的是优先考虑安全性，同时为优雅的错误留出空间并培养灵活性。 

一些 API 团队可能倾向于将使用其 API 的客户端应用程序视为事后考虑或未知数。但是，与客户端无关并不意味着您可以对前端安全性漠不关心或松懈。这些客户端应用程序是进入 API 的门户，您需要建立护栏以确保流量安全。 

通过定制 API 支持前端后端

过去 15 年，单页应用风靡一时，但最近，一些应用却从边缘退缩。退缩的原因之一是 SPA 的攻击面非常大，后端逻辑和数据有很多可能潜入前端的位置。 

一种在客户端复杂性和数据安全性之间取得更好平衡的设计模式是Backend For Frontend。API 产品团队可以成为实现 BFF 的强大合作伙伴，BFF 是 API 网关模式的一种变体。虽然 API 网关将客户端和服务器之间的连接集中在单个访问点，但 BFF 会为每个客户端创建一个特定的协调层，从而减少膨胀并限制前端暴露。 

作为 BFF 架构成功组件的 API 需要遵循一些最佳实践：

• 从 UI/UX 需求出发，定制适合不同平台的数据和身份验证方法
• 将通用方法与客户端特定数据隔离
• 围绕功能和待完成的工作设计端点，以限制不必要的数据暴露
• 遵循三原则减少重复代码，特别是在公共端点
• 使用行业标准的开源技术进行加密和授权

无论您的客户使用何种架构，大多数这些实践都将获得回报，但您的设计越能围绕实际用例，您就越能够创建既安全又灵活的 API 产品。

严格执行数据隔离

为了支持更安全的客户端应用程序，API 设计人员可以做的最重要的事情就是在尽可能少的位置存储尽可能少的敏感数据。无密码身份验证之所以成为一种圣杯，原因之一是它涉及的数据交换尽可能少——您实际上可以在不传输用户名的情况下进行身份验证，而客户端应用程序根本不会处理任何身份验证凭据。如果您将其扩展到数据层，这种严格程度会是什么样子？

与加密一样，一些行业对数据隔离有明确的标准。此外，任何希望在欧盟开展业务的公司都需要遵守《通用数据保护条例》（GDPR），该条例要求进行适当的数据隔离。即使这些因素不适用于您，合乎逻辑且一致的数据隔离实践也将帮助您创建我们一直在谈论的缓冲区！ 

人为错误是不可避免的，但如果你限制任何一个地方的敏感数据量，你就可以限制这些错误造成的后果。 

保护您的开发流程

您已尽最大努力确保您的 API 在设计上是安全的。您已与客户合作，了解他们的需求并支持他们构建安全的前端应用程序。您已反复阅读 OWASP Top 10。您已尽可能为您的个人帐户启用安全的 MFA 或无密码身份验证。但还有一个领域我们还需要讨论。

2022 年秋季和 2023 年冬季发生的 La​​stPass 事件始于一名恶意行为者截获了主密码。只有四个人知道这个密码，但对于一个有动机的黑客来说，找出哪些员工可能值得攻击并不难。一点点社交工程就可以迅速将攻击者引向高价值的网络钓鱼目标。如果这些人使用不安全的身份验证方法，很快就会造成巨大的损失。

您如何为内部团队制定安全措施？您如何筛选供应商？您采取了哪些措施来确保您的关键员工免受社交工程和网络钓鱼攻击？ 

如果你的生产系统不安全，那么你的产品也不安全。安全设计不仅包括保护你的设计资产、设计工具，还要确保设计师的访问凭证安全。人为错误在所难免。 

技术行业面临的挑战是继续支持协作和创新（API 经济的标志和优秀 API 产品的目标），同时将安全性作为顶级功能和设计重点。好消息是，您所需的知识和工具已经存在，Stoplight 和 Smartbear 等合作伙伴可以帮助您将它们付诸实践。

文章来源：API Passwords Stink! Freshen Up Your Security Practices