加盐:使用用户名是否合理?

当用户名更改时(如果可以更改的话),就会遇到问题。您无法更新哈希密码,因为您不存储未加安全设置的未加安全设置的密码。

我认为使用用户名作为salt值没有问题。

存储密码的一种更安全的方法是对每个记录使用不同的salt值。

如果查看ASP.NET成员资格提供程序的asp net_成员资格表,您会发现它们在几乎相同的记录中存储了密码、密码盐和用户名字段。因此,从这个角度来看,仅仅使用用户名作为salt值没有安全性差异。

请注意,有些系统对所有密码使用一个salt值,并将其存储在配置文件中。这里安全性的唯一区别是,如果他们能够访问一个salt值,那么他们就可以更容易地构建一个彩虹表来同时破解所有密码…

但是,同样地,如果他们能够访问加密形式的密码,那么他们可能能够访问存储在用户表中的salt值以及它……这可能意味着他们将有一个稍微困难的时间来计算密码值。

然而,在一天结束的时候,我相信几乎所有的应用程序在加密方面都会失败,因为它们 只有 加密表面上最不重要的数据之一:密码。真正应该加密的几乎是所有其他内容。

毕竟,如果我可以访问您的数据库,为什么我会关心密码是否加密?我已经可以接触到重要的事情…

很明显,比赛中还有其他的考虑,但是在比赛结束的时候,我不会为这件事操心太多,因为与其他人相比,这是一个小问题。

如果您使用用户名作为密码,并且您的应用程序有许多实例,那么人们可能会为特定的用户(如“admin”或“system”)创建彩虹表,就像Oracle数据库那样,或者像WPA(Cowpatty)那样使用一个完整的公用名列表。

你最好吃一个真正随机的盐,它不是那么难,它不会回来困扰你。

对于创建HTTP摘要身份验证的工作组来说,此方法被认为足够安全,该身份验证使用字符串“username:realm:password”的散列进行操作。

我认为你会很高兴看到这个决定是秘密的。如果有人窃取了您的数据库和源代码来查看您实际上是如何实现散列的,那么他们当时登录访问的是什么?在数据库中显示他们已经窃取的数据的网站?

在这种情况下,SALT为您的用户带来了一些安全好处。首先,如果窃贼有预先计算的值(彩虹表),他们将不得不为每个用户重新计算这些值,以便进行攻击;如果窃贼是在一个用户的密码之后,这不是一个大胜利。

第二,所有用户的散列值总是不同的,即使他们共享相同的密码,这样小偷就不会免费得到任何散列冲突(破解一个用户获得300个密码)。

这两个好处有助于保护可能在多个站点使用相同密码的用户,即使窃贼碰巧获取了其他站点的数据库。

因此,虽然密码散列的salt是最好保密的(在您的情况下,salt使用的确切数据是这样的),但即使它被破坏了,它仍然提供了好处。

随机Salting防止对同一用户名比较两个独立计算的密码散列。如果没有它,就可以测试一个人在一台机器上的密码是否与另一台机器上的密码匹配,或者密码是否与过去使用的密码匹配,等等,而不必使用实际的密码。即使在密码可用的情况下,它也可以极大地方便地搜索上述条件(因为可以搜索计算出的散列值,而不是为每个旧密码散列值单独计算散列值)。

至于这种预防是好事还是坏事,谁知道呢。

我知道这是一个古老的问题,但对于任何人来说都是基于这个问题寻找解决方案。

如果使用派生盐(与随机盐不同),则应使用键派生函数(如pbkdf2)加强盐源。

因此,如果您的用户名是“unhandledException”,则通过pbkdf2进行x次迭代,以生成32位(或您需要的任何长度的salt)值。

将x设为伪随机(与1000这样的偶数相反),并将特定于静态站点的salt传递给pbkdf2,这样一来,您的用户名salt将极不可能与任何其他站点的用户名salt匹配。