每次登录或哈希系统更改时，PHP SECURITY动态生成的用户哈希密码

Question

我知道这个网站http://www.openwall.com/phpass/，但主要是关于系统的想法。

示例，ZEND使用系统（'uname -a'）并将其散列到md5（）以使用ROW LEVEL用户SALT加密。这是用户密码，用户登录名/电子邮件地址和服务器名称的组合，如sha1 / md5 /...

但是，我的想法是生成 DYNAMIC SALT 而不是STATIC SALT，例如system（'uname -a'）。例如，每次用户登录时，SALT都已更改，但不是用户密码。

出于更多安全考虑，我需要每天在数据库或外部文件上动态更改salt，或者使用第三方检查来自其他服务器的数据进行腌制？

什么是保护用户数据表和当前登录用户敏感数据的最佳方法。 Cookie对我来说也是非常糟糕的安全选择。它必须适用于PayPal API Tokenize和用户ID ...

我正在使用当前：

来自每个用户的
1. 盐
2. 来自系统的盐哈希
3. 哈希用户密码，用户盐和系统盐的组合
4. SHA-512 crypt（）或bcrpyt（）类
5. 动态盐？想法？

Answer 1

你做错了。

我认为您错过了重新哈希密码的关键事实。要做到这一点，您必须将其存储在可恢复的格式中。因此，如果系统受到损害，则会产生更大的安全风险。

以下是我要做的事情：

• 使密码在60天后过期（或者，您可以选择其他一些号码，但不要太频繁）。
• 每次用户设置新密码时，都会生成随机盐
使用crypt()或CRYPT_SHA512哈希算法
• 使用CRYPT_BLOWFISH构建哈希
• 设置更高的轮次数量.20'000应该足够
• 将crypt()返回的整个结果存储在db。{/ li>的hash字段中

您也可以阅读：Properly Salting Passwords, The Case Against Pepper。

Answer 2

改变盐并没有改善任何事情。

关键是：你总是需要在某处将salt和hash存储在一起，因为当你将密码输入与散列进行比较时，你需要对输入进行散列 - 很明显，对吗？

所以这就是重点：即使您在每次登录后更改了盐并对密码进行了一些奇怪的重新散列，它也没有任何改变，因为一旦攻击者获得数据库，他就会同时使用哈希值和盐（如果存储的话）在一起，如果你总是为每个用户使用不同的盐，这是必要的，这是你应该做的事情。

更好的方法是通过使用1000-10000次散列和长盐来扩展散列（您可以轻松地使用512字节的盐）。这些比做重新散列更好。

但无论如何：如果你真的想改进你的PHP应用程序，你应该专注于避免SQL注入，XSS，CSRF，RFI，LFI，文件泄露，RCE等安全问题 - 如果攻击者可以访问服务器他只需后门登录脚本，每次有人尝试登录时都会向他发送包含明文凭据的电子邮件。 （好吧，如果您使用在CRAM-MD5 http://en.wikipedia.org/wiki/Challenge-response_authentication等javascript中实现的质询 - 响应身份验证，或者使用RSA（也在JS中实现）来安全地发送登录数据，您也可以避免这种情况。

Answer 3

Salt仅用于防止预计算攻击，例如Rainbow Tables。因此，如果有人想要强制散列，他们实际上必须在运行时一次计算一个。 （而不仅仅是在预先计算的散列值的数据库中进行查找）

你要解决的问题并不是很清楚。你只要说：

“出于更多安全考虑，我需要动态更改盐”

如果这个问题是预计算攻击，那么只需要正常的盐。如果它不是预计算攻击，那么盐几乎肯定是错误的解决方案。