我正在讨论使用用户名作为加密密码的方法，而不是随机字符串与名称一起存储。我的理由是盐的目的是防止彩虹表，那么是什么使得这实际上不如那里的另一组数据安全？
例如，
hash( md5(johnny_381@example.com), p4ss\/\/0rD)
vs
hash( md5(some_UUID_value), p4ss\/\/0rD)
是否有一个真正的原因我不能坚持使用用户名并简化操作？我的网络搜索产生的唯一一件事是关于盐应该如何喜欢一个密码的争论，但结束后没有任何理由，我认为这只是为了防止类似于在没有一百万年的范围内，一个可以使用的破解者可以对抗它。考虑到处理现实的局限性，如果人们知道哈希，我不相信这是一个大问题，他们仍然不知道密码，并且他们已经进入超级计算机范围以暴力破坏每个单独的哈希。
有人可以在这里赐教我吗？
答案 0 :(得分：13)
当用户名更改时（如果可以更改），您将遇到问题。您无法更新散列密码，因为您不存储未加密的，未散列的密码。
答案 1 :(得分：3)
我认为使用用户名作为盐值没有问题。
更安全的存储密码方法涉及为每条记录使用不同的salt值。
如果查看asp.net成员资格提供程序的aspnet_Membership表，您会看到他们已将密码，passwordsalt和username字段存储在几乎相同的记录中。因此，从这个角度来看，仅使用盐值的用户名没有安全性差异。
请注意，某些系统对所有密码使用单个salt值，并将其存储在配置文件中。安全性的唯一区别在于，如果他们获得了对单个盐值的访问权限，那么他们可以更轻松地构建彩虹表来立即破解所有密码......
但话说回来，如果他们可以访问密码的加密形式，那么他们可能会访问存储在用户表中的salt值以及它...这可能意味着他们会有一点点更难以确定密码值。
然而，在一天结束时，我相信几乎所有应用程序都在加密方面失败，因为他们仅加密表面上最不重要的数据之一：密码。什么应该真正加密几乎是其他一切。
毕竟，如果我可以访问您的数据库，为什么我会关心密码是否加密？我已经可以访问重要的事情......
显然还有其他一些考虑因素在起作用，但是在一天结束的时候，我不会过多地考虑这个因素，因为与其他人相比，这是一个小问题。
答案 2 :(得分：3)
如果您使用用户名作为密码并且您的应用程序有很多实例，那么人们可能会为特定用户创建彩虹表，例如“admin”或“system”，就像Oracle数据库的情况一样，或者是整个常见列表像WPA（CowPatty）那样的名字
你最好采取一种非常随机的盐，这并不困难，它不会回来困扰你。
答案 3 :(得分：1)
对于创建HTTP摘要身份验证的工作组，此方法被认为足够安全，该身份验证使用字符串“username：realm：password”的哈希值进行操作。
我认为你会很好看，因为这个决定是秘密的。如果有人窃取您的数据库和源代码以查看您实际实现散列的方式，那么他们当时登录访问了什么？显示数据库中已被盗的数据的网站？
在这种情况下，盐会为您的用户带来几项安全优势。首先，如果小偷有预先计算的值（彩虹表），他们将不得不为每个用户重新计算它们以进行攻击;如果小偷是在一个用户的密码后，这不是一个大赢家。
其次，所有用户的哈希值总是会有所不同，即使他们共享相同的密码，所以小偷不会免费获得任何哈希冲突（破解一个用户获得300个密码）。
这两项好处有助于保护在多个站点使用相同密码的用户，即使小偷碰巧获得了其他站点的数据库。
因此，虽然用于密码散列的盐最好保密（在您的情况下，盐的确切数据将是这样），但即使它受到损害，它仍然会带来好处。
答案 4 :(得分：1)
随机salting可防止对同一用户名的两个独立计算的密码哈希值进行比较。没有它，就可以测试一台机器上的人的密码是否与另一台机器上的密码匹配，或者密码是否与过去使用的密码相匹配等，而无需具有实际密码。即使密码可用，它也会大大方便搜索上述标准（因为可以搜索计算的哈希值，而不是分别为每个旧密码哈希值计算哈希值）。
关于这种预防是好事还是坏事，谁知道呢。
答案 5 :(得分：1)
我知道这是一个老问题，但是对于任何根据这个问题寻找解决方案的人来说。
如果使用衍生盐（与随机盐相反），应使用像PBKDF2这样的密钥派生函数来加强盐源。
因此，如果您的用户名是＆＃34; theunhandledexception＆＃34;通过PBKDF2传递x迭代，以生成32位（或您需要的任何长度盐）值。
使x伪随机（而不是像1,000这样的偶数）并将静态站点特定的盐传递给PBKDF2，并且您的用户名盐极不可能与任何其他站点的用户名盐匹配。< / p>