Possible Duplicate:
Best way to prevent SQL Injection in PHP
The necessity of hiding the salt for a hash

号

我对mysql和php非常陌生，在过去的几天里我已经开始自我学习，今天我正在研究密码加密等问题。我浏览了很多关于这个主题的网页，大多数网页都说要为表中的每个条目生成一个随机的salt(据我所知，你不想这样做)每个入口的盐)，然后这些盐应该存储在入口旁边的桌子上。

据我所知(如果我错了，请纠正我)，密码加密并不能阻止黑客访问它，而只是屏蔽了访问数据库时的真实值。当然，如果是这样的话，你也不想把salt存储在表中——如果黑客已经访问了数据库，并且能够看到加密的数据，向他展示salt只会让他的解密工作变得极其简单？

盐不用于加密。相反，它(与密码一起)进入一个哈希函数。这样，没有人(甚至你的应用程序)可以确定密码，但你可以验证密码。

然后，salt用于要求攻击者单独攻击每个密码散列(如果攻击者只需要一个密码，salt就没有任何帮助)。由于有了彩虹表，计算常用密码的哈希函数的输出相当容易。

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

以你计划的方式储存盐是非常好的。事实上，允许攻击者看到盐是可以的。salt的目的是通过扩展消息空间的大小，防止人们使用预先构建的名为彩虹表的查找表。所有的salt功能都是让它们放弃任何预计算，并解决整个问题，这是耗时的，但肯定是可能的(尤其是对于MD5这样的哈希，您应该转到sha256)

您希望为每个用户使用不同的salt，这样攻击者就必须为他们恢复的每个密码做全部的工作，而不仅仅是基于一个salt生成一个新表。

SALT的目的是防止使用彩虹表，这将允许黑客为某些密码生成大量预先生成的哈希。通过在散列前将salt附加到密码，散列与原始密码完全不同。

因此，他们需要为每个不实用的salt值重新创建哈希。

你可以把盐看作是"半独特的"，它实际上不必是额外的盐列。用户名、用户电子邮件也是一种盐。所以它们实际上存储在数据库中，靠近散列密码。当用户决定更改用户名或电子邮件时，这种方法会出现一个问题。