散列敏感数据

测试人员不应该作为合法用户登录。这显然违反了您正在执行的任何数据保护法案的不可否认性要求。

系统不应允许任何人使用哈希值登录。这违背了哈希的全部目的！

很抱歉我没有回答你的具体问题，但我真的认为你的整个测试系统应该重新评估。

添加：

JPLemme在下面的评论揭示了你在做什么，恐怕我完全误解了（大概那些投票给我的人也是如此）。

部分混乱是基于这样一个事实，即哈希通常用于加密密码，这样就没有人能发现另一个人的密码是什么，包括那些在系统上工作的人。显然，这是错误的上下文（现在我明白了为什么你要散列用户名而不仅仅是密码）。正如JPLemme所指出的，您实际上使用的是一个完全独立的parallel系统，实时数据已被复制和匿名，使用哈希（和盐水！）密码的安全登录过程不会受到干扰。

在这种情况下，WW下面的答案更相关，我建议每个人都把你的投票权交给他/她。很抱歉我误解了。

您不需要对数据进行散列。你应该把它随机化，这样它就和原始数据没有关系了。

例如，更新所有登录名，并用另一个随机字母替换每个字母。

我认为你在这里采取了错误的方法。哈希的想法是，它是单向的，没有人应该能够使用该哈希访问系统（如果他们可以，那么你很可能仍然违反了数据保护法。此外，测试人员不应该使用真实的帐户，除非这些帐户是他们自己的。

您应该让测试人员在一个单独的环境中使用模拟帐户。通过在单独的环境中使用模拟帐户，向测试人员提供帐户信息是没有危险的。

一般来说，最好使用自己的加密/哈希算法。现有的算法做它们所做的事情是有原因的。

给测试人员一个访问路径，为他们散列用户名，或者让他们复制/粘贴SHA-1散列，真的会这么糟糕吗？

根据定义，哈希是单向的。

如果你想保护的只是随意阅读数据（所以加密级别很低），那么做一些简单的事情，比如换位密码（不同字符之间的1-1映射——a变成J，B变成'-'，等等）。甚至只是把所有东西都换一个（IBM变成HAL）。

但要认识到，这绝不是隐私或安全的保证。如果这些都是你想要的品质，那么根据定义，你不能让测试人员模仿真正的用户。

此建议是否通过了贵组织的审计部门？如果不想，你可能想和他们谈谈，你使用的方案保护你的组织免受责任，这一点还不清楚。

为什么不使用测试数据生成器来识别个人？

在数据库中创建测试数据

为您提供更多信息：

我需要测试一个DTS包，该包将系统的所有用户从文本文件导入到我们的数据库中。我将得到实时数据。

然而，一旦数据进入数据库，就必须对其进行加扰，这样对于普通读者来说就没有意义了，而是允许测试人员登录到系统

感谢所有的答案。我认为你几乎肯定是对的，我们的测试策略是错误的。

我会看看我是否能改变的想法