API密钥是什么？为什么API密钥不一定安全？

一、API密钥的基本概念

API密钥是作为API访问控制的标识符，用于标识API请求的身份。API密钥向API提供商传递，并在每个API请求中用来验证API请求方的身份，并确定是否允许请求。API密钥通常是长字符串，并且必须通过HTTPS协议进行传输。

API密钥通常由API提供商提供，可用于授权对API的访问。使用API密钥，可以限制API的访问权限，以及允许或拒绝第三方应用程序访问API。在大多数情况下，API密钥是不可见的，只有在API调用时才用于验证API请求的身份。

举个例子，假设你正在开发一个应用程序，需要获取天气预报数据。你可以从某个天气预报API提供商处获取API密钥，该密钥用于访问其API。然后，你在应用程序中使用该API密钥向该API提供商发出请求，以获取天气预报数据。

二、API密钥的作用

API密钥可以用作API访问控制的标识符，以控制对API的访问和安全。使用API密钥可以使API提供商确定API请求方的身份，从而确定是否允许API请求。API密钥还可以用于记录API请求的数量，以及限制特定用户或应用程序对API的调用次数。

API密钥还可以用于监视API请求和限制对API的访问。如果API密钥泄露或被滥用，API提供商可以随时回收API密钥，以保护API的安全性。

三、API密钥的安全性

API密钥的安全性非常重要，它可以保护用户和应用程序的数据不被窃取或滥用。为了提高API密钥的安全性，API提供商可以提供以下几个建议：

1、不要在公共场合使用API密钥

API密钥是机密信息，不应被公开或分享。在开发过程中，API密钥可能会被包含在代码中。在部署应用程序或代码之前，请确保API密钥不会以明文形式出现在公共区域，如版本控制，日志文件，代码注释等。在代码中使用环境变量或配置文件存储API密钥是比较常见的方式。

2、设置好API密钥的访问权限

API提供商通常提供功能，使API密钥的访问权限可以与API的功能相对应设置。例如，你可以创建一个只允许读取天气预报数据，但不允许删除数据的API密钥。此外，可以将API密钥限制为特定IP地址或地理位置，在防止API密钥滥用和非法访问方面更加安全。

3、使用HTTPS协议传输API密钥

由于API密钥用于身份验证，因此必须确保API密钥不会被拦截或窃取。最简单的方法是在API请求中使用HTTPS协议传输API密钥。HTTPS是安全的，可以加密所有API请求和响应数据。这可以防止因网络拦截而导致API密钥泄露。

四、API密钥不一定安全的原因

我们都习惯于为数百个在线帐户使用用户名和密码 - 但如果管理不当，使用密码可能会分散注意力，并成为潜在的安全漏洞。在 API 领域也是如此。用户名本身并没有什么问题——你需要这些。但是，如果您在没有某种凭据的情况下使用它们，该凭据允许服务验证调用者的身份，那么您肯定做错了。

不幸的是，许多API提供商犯了一个危险的错误，暴露了大量数据并使整个生态系统不安全。用简单的英语来说——如果你只使用 API 密钥，你可能做错了！

什么是 API 密钥？

API 密钥是分配给特定程序、开发人员或用户的一段代码，每当该实体调用 API 时都会使用该代码。此密钥通常是一长串生成的字符，这些字符遵循创建它们的机构指定的一组生成规则：

在创建帐户或应用注册时，许多 API 提供商会向其开发人员分配 API 密钥，允许他们以类似于帐户用户名和密码的方式运行。API 密钥是唯一的，因此，许多提供商选择将这些密钥用作一种安全层，禁止任何无法为所请求的服务提供密钥的人进入和进一步的权利。

尽管在这种方法中使用 API 密钥具有诱人的简单性和易用性，但安全责任的转移、缺乏精细控制以及大多数开发人员对目的和用途的误解使得仅依赖 API 密钥成为一个糟糕的决定。我们不仅需要保护 API 密钥，还需要编写强大的身份控制和访问管理功能来保护整个 API 平台。

责任转移

在 API 密钥流程的最常见实现中，整个系统的安全性完全取决于开发人员使用者保护其 API 密钥和维护安全性的能力。但是，这并不总是稳定的。以安德鲁·霍夫曼（Andrew Hoffman）价值2375美元的Amazon EC2错误为例，该错误涉及将API密钥推送到GitHub。由于开发人员依赖于基于云的开发工具，因此 API 密钥的意外或恶意公开暴露可能是一个真正的问题。

从生成密钥的那一刻起，它就会通过具有有限加密和安全选项的连接通过网络传递给用户。一旦用户收到密钥（在许多常见实现中以纯文本形式提供），用户必须使用密码管理器保存密钥，将其写下来或保存到桌面上的文件中。API 密钥存储的另一种常用方法是设备存储，它获取生成的密钥并将其保存到请求它的设备上。

使用密钥时，API 提供商必须依靠开发人员来加密其流量、保护其网络并维护其安全交易。这里存在许多漏洞：包含密钥的应用程序可以被反编译以提取密钥，或者从设备上的存储中去混淆，明文文件可能会因未经批准的使用而被盗，密码管理器容易受到安全风险的影响与任何应用程序一样。

由于其相对简单，API Key 方法的最常见实现都提供了一种虚假的安全感。开发人员将密钥嵌入Github推送中，在第三方API调用中使用它们，甚至在各种服务之间共享它们，每个服务都有自己的安全警告。在如此脆弱的情况下，安全性是一个巨大的问题，但它并没有真正被API密钥提出，因为“它们是如此简单 - 用户会保证它们的安全！

这是一种鲁莽的观点。API 密钥仅在与 SSL 一起使用时才是安全的，这在方法的基本实现中甚至不是必需的。其他系统，如OAuth 2，Amazon Auth等，正是出于这个原因需要使用SSL。从用户体验的角度来看，将责任从服务提供商转移到开发人员消费者也是一个疏忽的决定。

缺乏精细控制

有些人原谅缺乏安全感。毕竟，开发人员有责任确保实施SSL等解决方案。但是，即使您确实保证了安全性，您的问题也不止于此——API 密钥在设计上缺乏精细控制。

有点讽刺的是，在API密钥与RESTful服务一起使用之前，我们为SOAP服务提供了WS-Security令牌，这些令牌使我们能够通过更细粒度的控制来执行许多事情。虽然其他解决方案可以限定范围、受众、控制和管理到最小的细节，但 API 密钥通常只提供访问权限，直到被撤销。它们不能被动态地专门控制。

这并不是说 API 密钥缺乏任何控制——相对有用的读/写/读写控制在 API Key 应用程序中绝对是可能的。但是，普通 API 开发人员的需求通常需要更全面的选项。

这也不是局部问题。随着越来越多的设备集成到物联网中，这种控制将变得比以往任何时候都更加重要，在开发早期阶段所做的选择在API生命周期的后期放大到巨大的比例。

圆孔中的方形钉子

所有这些都归结为一个事实：API 密钥从未被用作安全功能。大多数开发人员使用 API 密钥作为身份验证或授权的方法，但 API 密钥仅用于标识。

API 密钥最适合两件事：识别和分析。虽然分析跟踪（特别是 API 指标）可以成就或破坏系统，但其他解决方案以功能更丰富的方式实现此功能。同样，虽然 API 密钥在识别用户方面做得很好，但其他替代方案，例如公钥加密、HoK 代币等。在提供更多安全性的同时做得更好。

API 密钥的优点

使用 API 密钥肯定有一些正当的理由。首先，API密钥很简单。使用单个标识符很简单，对于某些用例，这是最佳解决方案。例如，如果 API 在功能上受到特别限制，其中“读取”是唯一可能的命令，则 API 密钥可能是一个合适的解决方案。无需编辑、修改或删除，安全性就不那么重要了。

其次，API 密钥可以帮助减少经过身份验证的服务中与熵相关的问题。熵 - 系统内在使用过程中不断消耗的能量或电位量 - 决定了身份验证对的数量有限。如果熵规定在限定为特定字符集和样式时只能有 6 万个唯一对，那么在遇到命名问题之前，您只能拥有 5 万个设备、用户或帐户。相反，建立具有大量可接受变量的API密钥在很大程度上解决了这个问题，将理论熵增加到更高的水平。

最后，API 密钥系统内的自主性非常高。由于 API 密钥独立于命名服务器和主凭据，因此可以自主创建它们。虽然这伴随着可能的拒绝服务攻击的警告，但创建的自治对于旨在利用它的系统来说非常棒。

在开发 API 时，应遵循最小特权原则 - 仅允许需要资源的人访问这些特定资源。这一原则取决于系统安全中CIA的概念——机密性、完整性和可用性。如果您的 API 不处理机密信息（例如，提供证券交易所代码的 API），不提供私有或任务关键型信息（例如新闻/RSS API），或者要求持续可用性（换句话说，可以间歇性运行），则 API 密钥可能就足够了。

此外，API 密钥是特定于开发人员的 API 用途的不错选择。当开发人员在操作时配置 API 客户端，并对不同的服务使用更改密钥时，这是可以接受的。

回到现实

在一般用例场景中，使用上述 API 密钥的好处仍然很微弱。虽然API密钥很简单，但“只读”的限制阻碍而不是解放。尽管它们提供了更高水平的熵，但此解决方案不仅限于 API 密钥，也是其他身份验证/授权解决方案所固有的。同样，可以通过创新的服务器管理和现代委派系统来实现自治。

结论：API 密钥不是一个完整的解决方案

当最终用户（而不是开发人员）开始使用这些密钥进行 API 调用时，API 密钥的巨大问题就会出现，这通常会使您的 API 面临安全和管理风险。归根结底，API密钥本质上不是一个完整的解决方案。虽然它们对于只读目的来说可能完全没问题，但它们的解决方案太弱，无法匹配高使用率 API 系统的复杂性。每当您开始集成其他功能（如编写、修改、删除等）时，您都必须进入识别、身份验证和授权领域。

基本 API 密钥实现不支持没有额外代码或服务的身份验证，它不支持没有匹配的第三方系统或辅助应用程序的身份验证，并且它不支持在没有一些严重“黑客”的情况下扩展使用超出其最初目的的授权。

虽然可以提出扩展API Keys方法以更好地支持这些解决方案的论点，但该论点将主张重新发明轮子。已经有这么多改进的解决方案可用，向 API 密钥系统添加功能没有意义。即使您确实使用Shibboleth，OpenID等向系统添加了诸如身份验证之类的东西，尤其是联合身份验证，也有很多系统已经支持此功能。

API 开发最重要的方面之一是创建完整、有效的安全解决方案。决定用于保护信息的技术和方法是迄今为止API开发生命周期中最重要的一步，因为在这一领域的一个失误可能会导致毁灭性的安全漏洞。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。