如何将一个人的身份与其个人数据分开？

Question

我正在编写一个应用程序，其主要目的是保留用户列表 购买。

我想确保即使我作为开发人员（或任何拥有完整能力的人） 访问数据库）无法计算出多少钱 特定的人已经花费或购买了东西。

我最初想出了以下方案：

    --------------+------------+-----------
    user_hash     | item       | price
    --------------+------------+-----------
    a45cd654fe810 | Strip club |     400.00
    a45cd654fe810 | Ferrari    | 1510800.00
    54da2241211c2 | Beer       |       5.00
    54da2241211c2 | iPhone     |     399.00

• 用户使用用户名和密码登录。
• 从密码计算user_hash（可能使用加盐等）。
• 使用哈希通过普通 SQL 查询访问用户数据。

如果有足够多的用户，几乎不可能知道有多少 特定用户仅仅知道他的名字就花掉了钱。

这是明智之举，还是我完全愚蠢？

Answer 1

恐怕如果您的应用程序可以将一个人链接到其数据，那么任何开发人员/管理员都可以。

您唯一能做的就是增加链接的难度，从而减慢开发人员/管理员的速度，但是如果您加大将用户链接到数据的难度，那么您的服务器也会变得更加困难。

---

基于@no idea 的想法：

您可以使用经典的用户/密码登录您的应用程序（散列密码或其他），以及用于保证数据安全的特殊“通行证”。此“通行证”不会存储在您的数据库中。

当您的客户登录您的应用程序时，我必须提供用户/密码/通行证。用户/密码与数据库进行检查，并且该通行证将用于加载/写入数据。

当您需要写入数据时，您可以对“用户名/通行证”对进行哈希处理，并将其存储为将客户端链接到数据的密钥。

当您需要加载数据时，您可以对“用户名/通行证”对进行哈希处理，并加载与该哈希值匹配的每个数据。

这样就不可能在您的数据和用户之间建立链接。

另一方面，（正如我在对 @no 的评论中所说）谨防碰撞。另外，如果您的用户写了一个错误的“通行证”，您将无法检查它。

---

更新：对于最后一部分，我有另一个想法，您可以在数据库中存储“密码/密码”对的哈希值，这样您就可以检查您的“通行证”是否正常。

Answer 2

1. 使用以下命令创建用户表：
   1. user_id：身份列（自动生成的 ID）
   2. 用户名
   3. 密码：确保其经过哈希处理！
2. 创建一个产品表，如您的示例所示：
   1. 用户哈希
   2. 项目
   3. 价格

user_hash 将基于永不改变的 user_id。用户名和密码可根据需要自由更改。当用户登录时，您可以比较用户名/密码来获取 user_id。您可以在会话期间将 user_hash 发送回客户端，或者发送加密/间接版本的哈希值（可以是会话 ID，服务器将 user_hash 存储在会话中）。

现在您需要一种方法将 user_id 散列到 user_hash 中并对其进行保护。

1. 如果您按照 @no 建议在客户端执行此操作，则客户端需要具有 user_id。存在很大的安全漏洞（尤其是网络应用程序），哈希值很容易被篡改，并且算法可以免费向公众开放。
2. 您可以将其作为数据库中的函数。坏主意，因为数据库拥有链接记录的所有部分。
3. 对于网站或客户端/服务器应用程序，您可以将其放在服务器端代码中。好多了，但随后一名开发人员就可以访问哈希算法和数据。
4. 让另一位开发人员编写哈希算法（您无权访问该算法）并作为 TCP/Web 服务连接到另一台服务器（您也无权访问该服务器）。然后，您的服务器端代码将传递用户 ID 并获取哈希值。您不会有算法，但您可以发送所有用户 ID 以获取其所有哈希值。尽管该服务可以进行日志记录等以尽量减少风险，但对#3 来说并没有太多好处。
5. 如果它只是一个客户端数据库应用程序，那么您只有选择#1和2。我强烈建议添加另一个服务器端的[业务]层，与数据库服务器分开。

编辑：
这与前面的一些观点重叠。有 3 台服务器：

• 身份验证服务器：员工 A 可以访问。维护用户表。具有采用用户/密码组合的网络服务（具有加密通信）。哈希密码，在表中查找 user_id，生成 user_hash。这样你就不能简单地发送所有 user_ids 并取回哈希值。您必须拥有密码，该密码不会存储在任何地方，并且仅在身份验证过程中可用。
• 主数据库服务器：员工B有权访问。只存储user_hash。没有用户名，没有密码。您可以使用 user_hash 链接数据，但实际的用户信息在其他地方。
• 网站服务器：员工 B 有权访问。获取登录信息，传递到身份验证服务器，获取哈希值，然后处理登录信息。将哈希保留在会话中以写入/查询数据库。

所以员工A有user_id、用户名、密码和算法。员工 B 拥有 user_hash 和数据。除非员工 B 修改网站以存储原始用户/密码，否则他无法链接到真实用户。

使用 SQL 分析，员工 A 将获得 user_id、用户名和密码哈希（因为 user_hash 是稍后在代码中生成的）。员工 B 将获得 user_hash 和数据。

Answer 3

请记住，即使没有在任何地方实际存储该人的识别信息，仅将足够的信息与相同的密钥相关联就可以让您找出与某些信息关联的人的身份。举个简单的例子，您可以打电话给脱衣舞俱乐部并询问哪个顾客开着法拉利。

因此，当您对医疗记录进行去识别化处理（用于研究等）时，您必须删除 89 岁以上的人的生日（因为年龄超过 89 岁的人非常罕见，特定的出生日期可能指向一个人）并删除任何指定人口少于 20,000 的区域的地理编码。 （参见http://privacy.med.miami.edu/glossary/xd_deidentified_health_info.htm< /a>)

AOL 在发布搜索数据时发现，只要知道哪些搜索与匿名者相关，就可以识别人们的身份。 （参见http://www.fi。 muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdf）

Answer 4

确保数据无法与其所属人员关联的唯一方法是首先不记录身份信息（使所有内容匿名）。然而，这样做很可能会使您的应用程序毫无意义。你可以让这件事变得更难做，但你不能让它变得不可能。

将用户数据和识别信息存储在单独的数据库（也可能在单独的服务器上）并使用 ID 号将两者链接起来可能是您可以做的最接近的事情。这样，您就尽可能地隔离了两个数据集。您仍然必须保留该 ID 号作为它们之间的链接；否则，您将无法检索用户的数据。

此外，我不建议使用散列密码作为唯一标识符。当用户更改密码时，您必须检查并更新所有数据库，以将旧的哈希密码 ID 替换为新密码 ID。使用不基于任何用户信息的唯一 ID 通常要容易得多（以帮助确保其保持静态）。

这最终成为一个社会问题，而不是一个技术问题。最好的解决方案将是社会解决方案。在强化您的系统以防止未经授权的访问（黑客等）之后，您可能会在与用户建立信任并实施有关数据安全的政策和程序系统方面取得更好的进展。包括对滥用客户信息的员工的具体处罚。由于一次违反客户信任就足以毁掉您的声誉并赶走所有用户，因此具有“顶级”访问权限的人滥用这些数据的诱惑比您想象的要小（因为公司倒闭通常超过任何收益）。

Answer 5

问题是，如果某人已经拥有数据库的完全访问权限，那么他们将记录链接到特定的人只是时间问题。在数据库的某个位置（或应用程序本身），您必须在用户和项目之间建立关系。如果某人具有完全访问权限，那么他们将可以访问该机制。

绝对没有办法阻止这种情况。

现实情况是，通过完全访问，我们处于信任的位置。这意味着公司经理必须相信，即使您可以看到数据，您也不会对其采取任何行动。这就是道德等小事情发挥作用的地方。

也就是说，现在很多公司将开发人员和生产人员分开。目的是使开发人员不再直接接触实时（即真实）数据。这具有许多优势，其中安全性和数据可靠性是最重要的。

唯一真正的缺点是一些开发人员认为他们无法在没有生产访问权限的情况下解决问题。然而，事实并非如此。

制作人员将是唯一可以访问实时服务器的人。他们通常会受到更大程度的审查（犯罪历史和其他背景调查），这与您必须保护的数据类型相一致。

这一切的关键在于，这是一个人事问题；而不是真正可以通过技术手段解决的问题。

---

更新

这里的其他人似乎遗漏了这个难题中非常重要且至关重要的一块。也就是说，数据被输入系统是有原因的。这个理由几乎是普遍的，因此可以分享。在费用报告的情况下，输入该数据以便会计可以知道应该偿还谁。

这意味着系统在某种程度上必须在数据输入人员（即销售人员）登录的情况下匹配用户和项目。

而且因为该数据必须绑定在一起，而所有相关方都不能站在那里输入一个安全代码来“释放”数据，那么 DBA 绝对能够查看查询日志来找出谁是谁。而且无论您想在其中添加多少哈希标记，我都可以轻松添加。三重 DES 也救不了你。

归根结底，您所做的只是使开发变得更加困难，安全效益绝对为零。我怎么强调都不为过：向 dba 隐藏数据的唯一方法是 1. 该数据仅可以由输入数据的人访问，或者 2. 不能访问该数据首先存在。

关于选项 1，如果唯一可以访问它的人就是输入它的人……那么，它就没有必要存在于公司数据库中。

Answer 6

看来你在这方面是正确的，但你只是想太多了（或者我根本不明白它）

编写一个函数，根据输入构建一个新字符串（这将是他们的用户名或其他东西）否则无法随时间改变）

在构建用户哈希时使用返回的字符串作为盐（我再次使用用户 ID 或用户名作为哈希生成器的输入，因为它们不会像用户的密码或电子邮件那样更改）

关联所有用户操作与用户哈希。

只有数据库访问权限的人无法确定用户哈希到底意味着什么。即使尝试通过尝试不同的种子、盐组合来进行暴力破解，最终也将毫无用处，因为盐被确定为用户名的变体。

我认为您已经在最初的帖子中回答了您自己的问题。

Answer 7

实际上，有一种方法可以实现您正在谈论的内容...

您可以让用户将其姓名和密码输入到运行纯客户端脚本的表单中，该脚本会根据名称和密码生成哈希值。该哈希值用作用户的唯一 ID，并发送到服务器。这样服务器只能通过哈希值而不是名称来识别用户。

不过，要实现这一点，哈希值必须与正常的密码哈希值不同，并且用户需要额外输入一次名称/密码，然后服务器才能“记住”该人购买的商品。

服务器可以记住用户在会话期间购买的商品，然后“忘记”，因为数据库不包含用户帐户和敏感信息之间的链接。

编辑

回应那些说客户端哈希存在安全风险的人：如果你做得正确，就不会存在安全风险。应该假设散列算法是已知的或可知的。反之则相当于“通过默默无闻实现安全”。散列不涉及任何私钥，动态散列可用于防止篡改。

例如，您采用如下哈希生成器：

http://baagoe.com/en /RandomMusings/javascript/Mash.js

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <[email protected]>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

看看 n 如何变化，每次对字符串进行哈希处理时，都会得到不同的结果。

• 使用普通的哈希算法对用户名+密码进行哈希处理。这将与数据库中“秘密”表的键相同，但不会与数据库中的其他任何内容匹配。
• 将哈希传递附加到用户名并使用上述算法对其进行哈希处理。
• Base-16 编码 var n 并将其附加到带有分隔符的原始哈希中。

这将创建一个唯一的哈希（每次都会不同），系统可以根据数据库中的每一列检查该哈希。该系统可以设置为仅允许特定的唯一哈希一次（例如，每年一次），从而防止 MITM 攻击，并且用户的任何信息都不会通过网络传递。除非我遗漏了什么，否则这没有什么不安全的。