Question

如果我有一个随机的，16个字符长的字母数字盐（不同的情况），每个用户生成和存储，我是否还需要一个全站点的盐？

换句话说，这样好吗？

sha1($user_salt . $password)

我应该这样做吗？

sha1($user_salt . $password . $site_salt)

此外，

目前，我有一个加密的cookie，用于查找数据库中的会话。在此会话中，有一个user_id和一个user_token。然后我使用user_id查询数据库 - 如果DB === user_token中的user_id + hash的sha1，则允许用户通过。

我在每个页面加载时对user_id进行第二次查询，这样如果我删除，禁止或更改用户的密码，该操作立即生效。

这是我在这里通过网站和问题查看的内容。你怎么看？我错过了什么吗？

我需要添加角色检查，但这可能会添加另一个查询（第3个仅用于auth）。有什么提示吗？

Answer 1

不，你不需要全网盐。盐被用来使彩虹桌无用。如果你真的想要使用网站范围的盐，但我认为没有必要。

我认为如果您的数据库遭到入侵并且有人意识到您的密码是用盐进行哈希处理的，那么他们会转移到安全性较低的下一个网站（除非您正在运行一个值得黑客入侵的网站 - 您可能有机会不是：P）

Answer 2

使用“站点范围”的盐可能很有用。这意味着您的数据库不仅必须受到攻击，而且您的源代码必须也是如此，以便真正理解您的密码方案。

我称之为“盐”和“胡椒”方法。每个用户存储的盐，辣椒是整个网站的价值。

<强>盐
每人独特盐的目的是使彩虹表无效。 salt通常存储在数据库中，并附加或附加到密码。有人意识到这一点仍然可以为每个用户运行基于字典的攻击，但关于盐的好处是他们不能将彩虹表用于这种常见的字典术语。

<强>辣椒
我称之为“胡椒”的目的是为每个密码添加一个可能未知的字符串，这意味着考虑盐的暴力字典攻击只会因为缺少胡椒而错过。这也意味着每个字符检查的暴力需要“发现”更长的密码，这可能需要更长的时间。一旦辣椒被发现，这些好处就会消失。

Answer 3

sha1($user_salt . $password)

这是常见的，但它并不好。

典型的最终用户密码长度约为8个字符，大部分都保留为7位ASCII字符集。因此，典型的密码大约是64位随机数据或更少。现代parallel brute-force attacks可以通过简单地尝试所有可能的密码来打败这个。使用SHA256或SHA512并不会实质性地改变结果，因为最终用户密码是限制因素。

从我在Stack Overflow上的阅读中，似乎有两种关于密码存储的思想：

您应该使用computationally expensive approach like BCrypt or scrypt。这样蛮力攻击就变得不可行了。这是有效的，代价是当用户登录时需要从服务器获得更多的CPU能力。请参阅此excellent article for an overview of the rationale。
第二种想法是，尽管BCrypt和scrypt肯定有效，但它们对于多用户应用程序来说是不受欢迎的，因为它们占用了太多的CPU时间 - 使最终用户等待，或者可能打开拒绝服务攻击通过发送大量的身份验证请求。请参阅lengthy discussion here（请务必阅读评论）。

目前，我有一个加密的cookie，用于查找数据库中的会话。在此会话中，有一个user_id和一个user_token。然后我使用user_id查询数据库 - 如果DB === user_token中的user_id + hash的sha1，则允许用户通过。

您未提及的安全会话处理的一个要点是SSL everywhere to guard against Sidejack。并且用户ID通常不利于安全性，因为它们通常是可猜测的（自动递增主键），或者它们错误地以URL等结尾。您是否可以使用经过同行评审的代码库，而不是滚动您自己的会话处理系统？

Answer 4

目前，我已经加密了   cookie，查找一个会话   D B。在这个会议中，有一个   user_id和user_token。然后我   使用user_id查询数据库 - 如果   DB ===中user_id + hash的sha1   user_token，然后允许用户   通过

我为user_id做第二个查询   在每个页面加载，如果我   删除，禁止或更改密码   一个用户，该动作立即生效   效果。

只有在这里出现错误的情况下才会发表评论：

您提到Cookie已加密
你的意思是user_id + hash的sha1
你提到了对密码更改敏感的第二个查询（我不清楚它是什么查询）。

这听起来很像你在cookie中存储密码或密码哈希，而不是在cookie中存储会话标识符。我建议反对。最大的原因是使用这样的密码衍生物很有可能将衍生品变成等效的密码。

换句话说，攻击者需要的只是密码的哈希值，而不是密码本身才能有效地进行身份验证。这样做的问题是，除非密码更改（不在您的控制之下），否则密码的哈希值不会更改，而只要您满意就会更改会话ID。

我的建议（如果您希望会话对密码更改敏感）是在密码更改时更改会话ID。

Answer 5

听起来您正在尝试重新创建DIGEST-MD5或SCRAM。这两种方法都允许您存储一个非密码字符串，该字符串对您的站点是唯一的，并且可以与另一方进行质询/响应，以验证他们是否拥有密码字符串，而无需在线路上发送密码字符串。

密码，盐和auths

5 个答案: