在MySQL表中存储盐是否安全?

时间:2012-07-29 20:39:21

标签: php mysql encryption salt

  

可能重复:
  Best way to prevent SQL Injection in PHP
  The necessity of hiding the salt for a hash

我是MySQL和PHP的新手,并且在过去的几天里开始自学它,今天我一直在寻找密码加密技术。我一直在寻找关于这个主题的信息的许多网页他们中的大多数人都说要为表中的每个条目生成一个随机盐(据我所知,你不希望每个条目使用相同的盐),然后将这个盐存储在条目旁边的表中。

从我的理解(纠正我,如果我错了),密码加密不会阻止黑客访问它,而只是掩盖真正的价值,如果他们可以访问数据库。当然如果是这种情况,你也不希望将盐存储在表中 - 如果黑客已经访问了数据库并且可以看到加密数据,那么向他显示盐只会让他的解密工作变得更容易吗?

4 个答案:

答案 0 :(得分:3)

salt不用于加密。相反,它(与密码一起)进入hash function。这样, nobody (甚至不是您的应用程序)都可以确定密码,但您可以验证密码。

然后使用盐来要求攻击者单独攻击每个密码哈希(如果攻击者只想要一个密码,则盐无论如何都没有帮助)。感谢rainbow tables,计算常用密码的哈希函数输出相当容易。

salt值不是秘密,可以安全地存储在MySQL数据库中(甚至发布)。

答案 1 :(得分:2)

salt的目的是阻止Rainbow tables的使用。这将允许黑客为某些密码生成大量预生成的哈希值。通过在密码被哈希之前将盐附加到密码,哈希与原始密码完全不同。

password => 5f4dcc3b5aa765d61d8327deb882cf99
password+saltvalue => 1d7dc54c316b11f3a38cc24fa68e2b6a
因此,他们需要为每个盐值重新创建哈希值,这是不切实际的。

答案 2 :(得分:2)

以您计划的方式储存盐是完全正常的。事实上,允许攻击者看到盐是可以的。 salt的目的是通过扩展消息空间的大小来防止人们使用名为rainbow tables的预构建查找表。所有的盐都会让他们抛弃任何预计算并解决整个问题,这很费时但是肯定是可能的(特别是对于像md5这样的哈希 - 你应该转移到sha256)

您希望为每个用户使用不同的盐,以便攻击者必须为他们恢复的每个密码执行全部工作,而不是仅根据单个盐生成新表。

答案 3 :(得分:-1)

您可以将盐视为“半独特”的东西,它实际上不必是名为salt的附加列。用户名,用户邮箱也是一种盐。所以它们实际上存储在db中,在哈希密码旁边。当用户决定更改用户名或电子邮件时,会出现此方法的一个问题。