1

我有一个名为employees3 列的表：FirstName、LastName和SSN。

.Net 服务每晚将数据输入此表，我不愿意更新。

我想要一个触发器，上面写着：

嘿，我看到你正试图在 SSN 列中插入一些东西......让我们在它进入之前对其进行哈希处理。

4

2 回答 2

4

一种方法是使用 INSTEAD OF TRIGGER：

CREATE TRIGGER dbo.HashSSN
ON dbo.tablename
INSTEAD OF INSERT
AS
BEGIN
  SET NOCOUNT ON;

  INSERT dbo.tablename(FirstName, LastName, SSN)
    SELECT FirstName, LastName, HASHBYTES('SHA1', SSN)
    FROM inserted;
END
GO
于 2012-08-20T19:24:43.693 回答
3

业务规则合规性和暂存表

另一种方法是不插入到最终表中，而是使用临时表。暂存表是一种永久临时表，它没有约束，允许NULLs，位于诸如此类的模式中，import并且只是外部数据源将数据放入其中的容器。其概念是可以设置具有适当业务逻辑的业务流程来对容器中的数据进行操作。

这是一种“数据清理”层，可以在其中完成 SSN 散列，以及其他业务流程操作或正在执行的业务规则，例如可空性或允许遗漏、大写、长度、命名、重复消除、键查找、更改通知等，然后最后执行插入。这样做的好处是一组坏数据，而不是被试图插入，被强制回滚，然后炸毁原来的进程，而是可以被检测到，完好无损地保存并最终得到妥善处理（例如被移动到错误队列、发送的通知等）。

许多人会使用 SSIS 来完成这样的任务，尽管我个人发现 SSIS 很难使用，因为它存在的问题包括脆弱性、难以使用包含临时表的 SP、部署挑战、不是数据库备份的一部分等等。

如果这样的方案对您来说太过分了，以至于您甚至都不会考虑它，请退后一步并考虑一下：您有一个外部进程，它应该插入正确、准确、已清理和肯定已知的数据放入表中。但是，它没有这样做。相反，它插入了不符合业务规则的数据。我认为触发触发器可能是一种处理它的方法，但这也是一个让您更多地思考系统架构并探索为什么首先会遇到这个问题的机会。

您认为不可信或不符合业务规则的数据应该如何变得可信且符合业务规则？诸如散列 SSN 列之类的转换任务属于哪里？

插入过程是否应该知道这样的业务规则？如果是这样，这在整个组织、架构、插入器的流程类型中是否一致？如果没有，你将如何解决这个问题，所以你不会在 kluges 上修复补丁？

SSN 哈希的不安全性

此外，我想指出其他一点。如果没有 TIN，则可能只有大约 8.89 亿个 SSN (888,931,098)。您认为遍历所有这些并将哈希与表中的哈希进行比较需要多长时间？散列当然会减少快速曝光——你不能轻易地读出 SSN。但鉴于只需要 10 亿次尝试，根据资源和计划，将它们全部弹出只需几天甚至几小时的时间。

包含所有 SSN 及其 SHA1 哈希值的彩虹表仅占用 25-30 GB 的量级——即使在相对便宜的家用计算机上也可以实现，一旦创建它就可以在瞬间弹出任何 SSN。即使使用更长或更昂贵的哈希值也无济于事。在几天或几周内，可以建造一张彩虹桌。如今，几百美元可以购买数 TB 的存储空间。

您可以对 SSN 哈希进行加盐，这意味着如果有人对您的表进行暴力破解，他们将不得不为每一行执行一次，而不是一次获取所有行。这当然更好，但它只会延迟不可避免的事情。一个严重的黑客可能有一个僵尸军队支持他，可以在几秒钟内破解一个简单的 SSN + salt。

进一步的想法

我会对业务规则感兴趣，这些规则一方面要求您能够验证 SSN 并将其用作一种密码，但另一方面不允许您存储完整值。您对数据库有安全顾虑吗？既然你已经更新了你的问题，说这些是员工，我关于为什么排除非 SSN 持有者的问题是没有实际意义的。但是，我仍然很好奇为什么您需要对这些值进行哈希处理而不能只存储它们。雇主拥有员工的 SSN 不仅可以，而且还要求它可以向政府报告收入和扣除额。

另一方面，如果您真正关心的不是安全性，而是更多关于可否认性（“您的 SSN 永远不会存储在我们的服务器上！”），那么这不是真的，现在，是吗？您所做的只是以一种可以通过蛮力逆转的方式对其进行转换，并且搜索空间足够小，蛮力是相当合理的。如果有人给你数字 42，你把它乘以 2 并保存 84，然后告诉这个人他的数字没有被存储，但你可以简单地将 84 除以 2 得到原始数字，那么你不是真的完全直截了当。

当然，“单向”散列比乘法更难逆转，但我们不是在处理诸如“从其散列中找到原始的 20 万字符文档（或其他）”之类的问题，而是“找到一个 9 位来自其哈希的数字”。当然，许多不同的输入将散列到与一个特定 SSN 相同的值，但我怀疑是否存在很多完全由数字组成的 9 字符字符串的冲突。

实际 SHA-1 SSN 哈希反转测试

我只是做了一些测试。我有一张桌子，里面有大约 3200 个真实的 SSN。我使用 SHA1 对它们进行哈希处理，并将这些哈希值放入仅包含一列的临时表中。我能够在大约 8 分钟内弹出 1% 的 SSN，从001-01-0001. 根据处理速度和总搜索空间，它将在不到 3 小时内完成（每 1000 万个 SSN 大约需要 2 分钟，因此 88.89 * 2 分钟）。这是来自SQL Server内部，而不是运行一个可以更快、更快的编译程序。这不是很安全！

于 2012-08-20T21:20:09.243 回答