Possible Duplicate:
Encrypting/Hashing plain text passwords in database

最近，我发现主要的网络托管公司在试图验证他们的身份时，会以明文形式存储他们的用户密码，甚至要求输入用户密码的最后4位数字。这似乎是大错特错，充满了安全问题。我相信他们这样做的原因只是为了帮助识别用户。

1a)不要存储用户的密码，只存储一个(咸的)散列密码。当用户登录时，散列他们提供的密码，并将其与存档的散列进行比较。如果你不知道用户的真实密码，你就不能破坏它的安全性。

1b)很难通过电话安全地识别用户，您的努力程度将取决于未经授权访问帐户的"危险"程度。我的银行账户要求我从我的家、工作或手机号码(我已经提前列出)打电话。您可以要求呼叫者验证您在文件中随机选择的账户信息(如账号、账单邮政编码、中间名首字母、出生日期、信用卡号中的第七位数字等)。一些基于电话的系统具有不同于普通密码/密码的每个用户的密码。您可以通过短信向呼叫者的手机发送一次性密码，并要求他们在一定时间内将密码输入系统。我看到的一个更安全的系统使用Verisign的VIP移动应用程序生成一次性密码。(当然，如果有人偷了你的手机，也没什么帮助)

2)我怀疑信息是公开的。如果有一个不安全存储用户帐户信息的公司列表，它将加倍作为"请黑客我"列表，这些公司将受到入侵企图的猛烈抨击。

关于1-正确的方法是完全不存储密码。相反，存储一个盐散列的密码。

至于在不要求密码的情况下安全地识别用户，这是一个棘手的问题。从本质上讲，任何您用来识别它们的东西都会变成另一个密码(与第一个密码的存储问题相同)。实际上，大多数服务都会使用一些其他的个人信息——SOC的最后4位数字。秒。号码、母亲的婚前姓或"安全问题"。不过，几乎可以肯定的是，所有这些都不如一个好的密码安全。

解决问题的第一部分：不要存储密码。存储密码散列，加盐。

为了通过电话识别他们，我可能会让他们事先验证一个电话号码，然后将其与一个他们可以定义的秘密问题结合起来使用。

遗憾的是，许多主机没有安全地存储密码。在这方面，我没有足够的经验来评论优秀的主持人。

一般来说，您根本不想存储密码——您存储的是一个咸密码散列。当他们想登录时，您可以将他们提供的密码进行salt和hash，并将结果与存储的hash进行比较。