如何实现共享密码数据库？

Question

在传统形式中，密码数据库与任何其他数据库文件相似，但内容是使用用户输入的密码短语派生的密钥加密的。用户输入密码，解密数据库，读取一些条目，写入/更改其他条目，重新加密数据库并将其写回磁盘。

假设我们希望将这个概念扩展到共享环境。假设我们的数据库有十个条目(0通过9)和三个用户(Alice、Bob和Carl)，每个条目都有自己独特的密码。更复杂的是，Alice应该能够访问所有条目，Bob应该只能访问条目0-4，Carl应该只能访问5-9条目。如果Alice更改了其中一个条目，Bob或Carl应该会看到更新的值(如果它们有访问权限)。如果Bob或Carl更改了它们可以访问的条目之一，Alice应该会看到更新的值。

我很好奇是否有这样的方法可以安全地实现。我想出的所有方法要么要求将某种“主”密钥存储在数据库旁边，从而为任何能够访问文件系统或服务器内存的人留下一个很大的机会--或者为每个用户存储每组条目的唯一加密副本。但这将打破一个用户需要以其他用户可以看到的方式更新值的场景。

是否有办法做到这一点，或一些微妙的方式，要求可以调整，使系统不那么自相矛盾？

Answer 1

我想了一下到目前为止发布的答案，在使用公钥算法的想法中有一个有趣的希望。仔细考虑一下，每个用户都可以拥有一个公钥/私钥对(其中每个公钥都存储在中央服务器与数据库一起)。

服务器上的公钥存储：

+-------+------------------------+
| Alice | [public key for Alice] |
+-------+------------------------+
| Bob   | [public key for Bob]   |
+-------+------------------------+
| Carl  | [public key for Carl]  |
+-------+------------------------+

每个条目将被加密存储，使用一个对称密码，每个条目的密钥由服务器在每次写入条目时随机生成：

+---+-------------------------------------------------+
| 0 | symmetric_cipher([plaintext 0], [random key 0]) |
+---+-------------------------------------------------+
| 1 | symmetric_cipher([plaintext 1], [random key 1]) |
+---+-------------------------------------------------+
|   ...                                               |
+---+-------------------------------------------------+
| 9 | symmetric_cipher([plaintext 9], [random key 9]) |
+---+-------------------------------------------------+

对于访问控制，第三个映射可以为每个条目存储随机生成的密钥，该密钥已使用每个授权用户的公钥加密：

+-------+---+-------------------------------------------------------+
| Alice | 0 | pubkey_cipher([random key 0], [public key for Alice]) |
+-------+---+-------------------------------------------------------+
| Bob   | 0 | pubkey_cipher([random key 0], [public key for Bob])   |
+-------+---+-------------------------------------------------------+
| Alice | 1 | pubkey_cipher([random key 1], [public key for Alice]) |
+-------+---+-------------------------------------------------------+
| Bob   | 1 | pubkey_cipher([random key 1], [public key for Bob])   |
+-------+---+-------------------------------------------------------+
|   ...                                                             |
+-------+---+-------------------------------------------------------+
| Alice | 8 | pubkey_cipher([random key 8], [public key for Alice]) |
+-------+---+-------------------------------------------------------+
| Carl  | 8 | pubkey_cipher([random key 8], [public key for Carl])  |
+-------+---+-------------------------------------------------------+
| Alice | 9 | pubkey_cipher([random key 9], [public key for Alice]) |
+-------+---+-------------------------------------------------------+
| Carl  | 9 | pubkey_cipher([random key 9], [public key for Carl])  |
+-------+---+-------------------------------------------------------+

(据我所知，这是GPG向多个收件人发送加密消息时所做的事情。)

每个用户都可以使用他们的私钥来解密对称的" entry“密钥，该密钥只对该特定条目有用。该密钥将允许他们解密和读取该条目。如果他们需要修改并重新保存它，他们可以使用与其读取和覆盖相同的密钥，或者服务器可以生成一个新的入口密钥，并为每个授权用户使用公钥来更新其他受影响的行。

取消授权用户就像从用户到条目映射表中删除他们的行一样简单。如果有人担心他们可能已经存储了一个或多个输入密钥，那么这些密钥都可以透明地为每个剩余的用户重新生成，而不需要他们的任何干预。

这样看来，主要的关注点将转移到确保客户端-服务器通信通道是安全的，并且客户端可以将其秘密保密。

Answer 2

对于每个共享数据库，使用随机生成的密钥进行加密。不要按原样存储密钥，而是将其存储为三份(Alice有一个用她的密码加密的密钥，Bob有一个用他的密码加密的密钥，等等)。如果Alice想要更改她的加密密码，那么首先解密她的密钥副本，然后用新密码对其进行加密；在这种情况下，底层随机生成的加密密钥不会更改，Bob和Carl的密钥因此仍然有效。-我想最好是进行某种盐渍；如果不是，人们很容易就能发现两个用户是否选择了相同的个人密码。

我不知道如何设置共享；您必须将真正的加密密钥从一个用户传输到另一个用户，而不会泄漏。也许您可以将密钥分成两部分(XOR使用加密随机字符串)，并在数据库系统中共享一半，而另一半则通过从屏幕到电子邮件的剪切粘贴方式共享？

祝好运。

Answer 3

如果您已经在每次写入时重新加密整个数据库，那么我认为为每个读者维护单独的数据存储(或以同样的方式维护一组读取器)不会有太大的飞跃。可能更有效的做法是为每个读者保留一个事务分类账，然后在元数据中为每个条目列表/表指定在验证写事务时要引用的写权限。

也许是这样的一个接口：

<writer>: <key> = <value> -> <reader>(<permissions>)

例如，此命令将标识作者，将3设置为"hello"，并定义授权用户：

Alice: 3 = "hello" -> Alice(r+u+d), Bob(r)

这可能会促使Alice的客户端对上述事务字符串进行签名，并对其进行两次加密--一次对Alice，一次对Bob--然后将事务执行到Alice、Bob，可能还有Carl和攻击者共享的持久内存中。Alice和Bob中的每个人都会查看和解密事务、验证权限和验证签名、将其应用于各自的数据库并查找新的数据库。

对于组权限，将Alice和Bob替换为示例右侧的组名，并根据需要(通过相同的机制或其他方式)添加元数据。每个事务都需要有时间戳来提供一个明确的变异顺序，但我想在这里保持简单。

本质上描述加密/通过身份验证的酒吧-潜艇，可能会对每个人加密的数据进行长期序列化，并由每个人自己备份到长期的持久内存中，以便能够在新机器上快速启动，并阻止在不太安全的个人媒体上进行长期存储(而不是让它们遍历整个事务总帐，并在同步过程中对它们进行顺序处理)。

当然，像这样的系统已经在已建立的代码库中实现了一种更有效/更实用的方法。我不知道任何一个，因为我不需要与这样的系统工作到目前为止，但我会四处看看，如果我找到答案和编辑。作为最后的想法，看看PGP如何在一种编码中支持多个消息接收者--它可能提供一些洞察力。