我面临着永无止境的问题如何在DB中存储密码？。据我最近读到，有一些以前被认为是安全的算法，这些算法被标记为不安全。所以我很难找到一个最新的资源来描述那些不再安全的资源。
我在考虑将两个或三个算法结合起来，但我记得当时它被认为是不安全的，即将哈希暴露给攻击。我想到的组合是这样的：
data_h1 = sha256(sha1(data_salt).sha1([username|email]).sha1(data_peper))
data_h2 = sha256(sha1(data_salt).sha1(user_entered_password).sha1(data_pepper))
hmac(
sha512,
data,
sha512(general_salt.data_h1.data_h2.general_pepper)
);
data_salt 和 data_pepper 是常量，硬编码到应用程序中，但与 general_salt和general_pepper 不同硬编码常数。 [username | email] 是用户在注册时和登录时提供的值，以及* user_entered_password *（doh！）。
我的问题适用于PHP，但很高兴看到你们会推荐什么以及你的评论一般是什么，b`cuz我认为这是非常常见的任务，很多人仍然只使用MD5或SHA1（或更好，以纯文本格式存储）。
答案 0 :(得分：4)
不单独使用SHA-1或SHA-256进行散列密码的主要原因是 相对而言，它们快速。密码身份验证易受字典攻击 攻击和暴力攻击，因为用户往往在其密码中包含常用词 并使用相对较短的密码，使其比加密密钥更容易猜测。
建议使用像bcrypt和PBKDF2这样的散列函数，因为它们慢。
他们可以调整几乎任何时间;它应该花费多长时间
可以散列密码而不会导致不合理的延迟。这将有助于减缓
字典攻击和暴力攻击。
但是，这不是密码存储的唯一安全考虑因素。
答案 1 :(得分：1)
当“存储”密码时，您实际上并未存储密码，而是存储其单向散列。这样做的原因是为了防止有权访问系统的人学习用户的密码。散列的“单向”方面意味着，虽然可以从明文创建散列，但是不可能从散列中学习明文。
此外，在进行哈希处理之前，所有密码都应与salt（随机数字序列）连接。 salt值应与数据库中的哈希一起存储。盐必须是ROW-SPECIFIC，即每个密码都应该有自己的盐。
为什么哈希必须是行特定的？想象一下，黑客已经以某种方式获得了数据库的副本。通常他会遇到一个相当大的暴力任务。如果您只有一个哈希，黑客可以检查所有行并找到最常出现的行，因为相同的密码+相同的盐总是呈现相同的哈希值。因此，通过这些信息，他可以猜测这些行包含常用密码。然后，他可以使用该信息来减少他的暴力问题的规模。或者他可以尝试学习其中一个用户的密码，然后能够在具有相同哈希的任何其他用户帐户上使用该密码。盐的全部意义在于防止这种性质的攻击。</ p>
使用具有用户特定盐的体面单向加密安全哈希。这是存储密码的标准方法。
添加特定于应用程序的“pepper”（每行都相同，并且必须加密随机并保存在安全位置）将哈希转换为HMAC（基于哈希的消息身份验证代码），这甚至是更好。如果有人知道你的哈希算法和盐但不知道胡椒，那么猜测密码就会困难得多。