我正在构建一个 Electron 应用程序并实现云存储支持。用户可以将我的应用程序中的文件上传到他们的帐户。作为管理员，我不希望能够通过 Firebase 管理控制台读取文件。我还想避免使用用户密码，因为人们可能会忘记它。只需登录他们的帐户就足以访问他们的文件。
在我的原型中，我将用户文件存储在
data/${user.uid}/围绕这个主题有几个问题涉及
DigitalOcean我在 Firebase 的文件存储中遇到了多种客户端加密选项。加密本身非常简单，可以使用对称密钥（既可以加密数据又可以解密加密数据的密钥）使用现有库来执行。正如通常的问题一样，我们现在需要找到一个安全的地方来存储这个万能的密钥。
选项 1：将密钥存储在用户设备上
优点：这会将密钥存储在用户的设备上，因此密钥永远不会在应用程序服务器中。 缺点：无法从其他设备访问密钥以及数据。根据用例和情况，这不是一个糟糕的解决方案。
选项 2：Google 加密密钥管理服务
优点：使用 Google 密钥管理服务中存储的另一个数据密钥对密钥进行加密。用户的密钥对数据进行加密，然后通过KMS密钥对密钥进行加密并存储在数据库中。正如 Andy 在他的博客中正确指出的那样，KMS 密钥属于与 Firebase 数据库不同的 Google 帐户，因此没有任何用户有权读取数据并解密数据。黑客需要破坏两个帐户才能访问未加密的数据。 缺点：用户必须管理两个帐户。
选项 3：将密钥隐藏在用户的 Google 帐户中
优点：当用户登录时，我们会从用户的 Google 帐户获取 OAuth 凭据来请求用户的个人加密密钥，如果找不到，则创建一个。这样，密钥始终完全掌握在用户手中，但他们永远不必直接处理它。 Google Drive 提供了用于创建特殊应用程序数据文件夹的 API（OAuth 期间需要用户同意）。该文件夹的内容对用户不可见，只能通过应用程序的凭据访问。 缺点：用户必须小心，不要意外删除自己的加密密钥。
选项 4：非对称密钥对
优点：用户首先获取收件人的公钥。然后，他为自己生成一个对称密钥，用该密钥对文件进行编码。然后，他为每个接收者创建该对称密钥的副本，并使用各自的公钥对其进行加密。最后，他将对称密钥的加密副本与加密文件一起传输到服务器并将其存储在那里。如果其他用户想要下载该文件，他会以加密形式获取该文件以及对称密钥的副本，即为他加密。他可以使用他的私钥解密后者，并且现在拥有可以解码文件的对称密钥。
选项 5：公钥和私钥加密
优点：在您注册用户时为他们创建私钥和公钥。使用用户 2 的公钥加密用户 1 设备上的数据。将加密数据存储在数据库中。当用户2读取加密数据时，他/她的私钥将能够解密它。