node.js - 服务如何生成和使用公共(public)和 secret API key ？

Question

Google、Stripe 和许多其他公司都有公共(public) API key 和 secret API key 。

生成随机字符串很容易，但我的问题是，如何生成公钥和私钥，存储它们并正确使用它们？

公共(public) API key 用于告诉用户是谁， secret 用于确认他们的身份。

我的流程如下:
- 用户创建一个帐户
- 用户激活服务(内部)
- 服务返回一个公共(public)和一个 secret API key (UARRHAtPtJcLxx5RmmWo9oTrca4gRt2k, C9YS7Mhzichq2vqBuRkNJxkNci5W2Xua)
- 用户在他/她的网站上使用公钥，在服务器端使用私钥

我正在使用 nodejs，并且当用户要求提供 API key 时，公钥是按需生成的:

let public = await crypto.randomBytes(32).toString('base64');

将 secret 存储在数据库中就像以明文形式存储密码一样。
我想我们不想要这个，它需要以某种方式散列。例如，我是否生成一个“私有(private)” key 并使用 argon2 对其进行哈希处理？用户将永远无法再次看到他/她的 key ，需要立即保存，这是一种好的做法吗？

我找不到太多关于这应该如何工作的信息。

Answer 1

从技术上讲，您所指的只是用户名和密码。唯一重要的区别是这些通常由 API 生成并且非常随机，而不是由用户选择的真实用户名和密码，通常不是非常随机。 (调用这些公钥和私钥有点误导，因为公钥密码学是不同的——对于 API key ，您通常不需要它，管理 PKI 是一堆蠕虫，而且正确执行它的成本也很高。)
由于这些在技术上与用户名和密码相同，因此您希望以类似方式对待它们。我们称这些客户端 ID(“公共(public)”部分)和客户端 key (“ secret ”部分)。
一些想法:

您应该使用加密安全的随机生成器来生成随机字符串。 crypto.randomBytes()如上是好的。

您应该考虑熵来为 key 设置适当的长度。熵基本上是 key 的“随机性”，以位为单位。举个例子，如果 key 空间是 1024 个具有相同概率的不同可能 key ，那么您可以说 key 具有 log2(1024) = 10 位熵。熵将 key 的长度与随机源的安全性分离，例如，您可以拥有仍然不安全的非常长的 key ，因为随机源存在缺陷。您想要多少熵取决于用例，例如在任何情况下是否可能进行离线攻击或仅在线请求等等(您可能也应该计算离线攻击，这非常快)。根据经验，熵不应低于 128 位，为了更高的安全性，您可能应该达到 256 位以上。如果 key 区分大小写和字母数字，则有 62 个不同的可能字符，长度为 22 的 key 提供约 131 位 (log2(62^22) =~ 130.99)。当然，您总是可以更长，对于 256 位，您需要长度为 43 且区分大小写的字母数字。

正如您正确指出的那样，存储此类 key 至关重要。至少，您希望将它们存储为散列(使用适当的散列，见下文)，就像任何其他密码一样，这样即使攻击者可以访问您的数据库，他们也不会看到您的 api key .任何适当的 key 派生函数(Argon2、bcrypt、PBKDF2 等)都适合此目的，但普通加密散列函数(sha1、sha2 等)则不适合。

你是对的，如果你对这些 secret 进行散列，用户将只能在它们生成时才能看到它们，并且永远不会再看到它们。这正是安全在线服务中发生的情况，通常是一种很好的做法。您可以警告您的用户注意该 secret ，因为您将无法再次显示它们。 (如果他们忘记了，他们也可以理想地生成一个新的，所以这通常没什么大不了的。)

更好的办法是将这些 key 存储在其他地方。考虑到云，存储此类 secret 的好地方是您的云提供商提供的服务，例如 AWS 中的 Secrets Manager。好处包括使用 KMS key 进行加密、审计，并且您可以确保访问您的 key 的唯一方法是通过适当的 IAM 角色(例如，您无需担心诸如公开备份之类的事情)。

虽然客户端 ID 不是 secret ，但您需要在存储中保护其完整性(以及与客户端 secret 关联的完整性)。想象一个场景，攻击者可以以某种方式更改您的数据库并将不同的(攻击者已知的)客户端密码分配给现有的客户端 ID。这将意味着与该客户端 ID 关联的数据的完全妥协。因此，您要确保除了保持客户端 secret 安全之外，攻击者也无法更改这些内容(例如通过对相关组件的访问控制)。