C# 防篡改表

我正在设计一个表，用于存储向客户收费的信息。
问题是数据库可能位于客户服务器上。
我正在考虑添加第二个包含第一个哈希的表，这样使用数据库的软件可以更新数据库和哈希，但是客户不能编辑（在我们不知道的情况下）包含收费信息的表（基于他们无法生成正确的哈希）

这是阻止客户篡改他们有权访问的表的好方法吗？
如何创建表中所有数据（可能不止一个表）的散列

具体地说，我需要在表中散列数据，而不是像dataset这样的对象（即，如果我们更改了组件，我不希望所有散列都更改）

我曾考虑将数据写入一个文本文件并创建该文件的散列，但这将非常缓慢，因为该表可能包含多达500000条记录，并且每次更新都需要生成散列

---

这可以在delphi或c#中实现。

我可能会先看看这个。下面介绍如何在SQL Server中加密列：

你将遇到的问题是，在某个时间点，你将不得不解密它。因为它在他们的机器上，而且你用来验证信息的代码也在那里，所以它永远不会是真正的防篡改的。他们可以查看您编译的代码，并找出如何绕过现有的安全机制

您还应该了解.Net的代码混淆

---

这不会阻止他们，但会让他们慢下来

我不太确定这是否解决了更大的问题（例如，如果有人使用虚拟机映像将服务器恢复到较早的日期以丢失最后几天的费用，这将无济于事），但是

许多散列算法被设计为 信息消化如此有效 逐渐地

Hash（concat（M，N），seed）==
散列（N，散列（M，种子））

您可以记录每个SQL更新 命令发送到数据库

---

这将为您提供独立于任何C#组件的更便宜的哈希值。

我们有一列，其中包含一个字符串值，该字符串值是来自多个系统相关值（许可证到期日期和其他值）的非常简单的哈希值。该值由程序在关键时刻动态重新计算。如果重新计算的值不匹配，我们将停止处理。该列还用作加密其他数据段的密钥。用于重新计算的过程是加密的

---

不是万无一失的，但比任何人都想通过作弊来完成更多的工作。到目前为止。

您的哈希解决方案听起来确实可以很好地工作。如果性能是一个问题，那么只使用随机样本验证哈希，或者使用计划作业更新哈希验证日期（可以加密）。如果使用更新触发器清除散列值，您可以轻松确定哪些记录被“修改”，并且您的程序可以在每次运行时验证触发器是否仍然存在。

散列可以工作，但您缺少另一个元素。为了生成无法重新生成的哈希值，您需要在哈希中包含一个秘密值。GUID可以工作，但它可以是客户不知道的任何值。当然，如果他们的计算机上有软件，那么他们可以想当然地发现算法和秘密值，从而绕过它。为每个客户使用不同的秘密值将是一个很好的额外保护级别，以防一个客户发现它

例如：

Hash([Table Data] + [Secret Value]) = [stored hash]

如果您只对表数据进行散列，那么他们可以简单地重新散列修改后的表数据，这样您就不会知道他们已经这样做了

至于如何散列整个表，而不是每一行，大多数散列都支持增量散列。原因是，如果要散列一个10GB的文件，可能没有足够的RAM将其全部加载到内存中进行处理。相反，您一次散列一个块，然后在完成后完成散列。您可以对数据使用相同的方法。只需将每一行添加到哈希中，一次添加一行，完成后完成哈希。当然，请记住包含您的密钥值

要记住的一些事情：

不要在你的应用程序中包含验证例程——换句话说，不要为他们提供一种方法来验证他们尝试的黑客行为是否有效或失败。这样做会给他们即时的反馈，让他们设计出最终的解决方案

确保您对这个系统进行了良好的测试，尤其是如果您计划在这些散列失败时惩罚您的客户

确保您的客户知道禁止篡改这些值。最好将其与表级加密结合起来，以防止意外修改

你最好把费用记录在网站之外。如果服务器已连接到internet，则让它将信息发送到您运行的web服务。为了获得更好的安全性，让web服务验证消息并用密钥响应。然后您可以在本地验证该密钥，以确保它们没有绕过web服务。这将是公钥消息签名的一个很好的应用

---

还要记住，大多数人都是诚实的，很多人只有在诚实的道路太痛苦的时候才会求助于规避（例如，测试中的假阳性，或者价格标签太贵）。通常情况下，偷东西的人不会为此付出代价。今天可能偷东西的人明天可能会付钱。你不想和你的客户打交道，把他们当作你的敌人，因为这样你们就都失去了。

为什么不只是按记录而不是按表进行散列呢

你可以这样连接

recordid  tableid  hash