-1

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

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

但是，我的想法是生成动态盐而不是静态盐，例如 system('uname -a')。例如，每次用户登录时，SALT 都已更改，但用户密码未更改。

出于更多安全原因，我需要每天动态更改数据库或外部文件上的盐，或者使用第三方，例如检查来自另一台服务器的数据是否加盐？

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

我正在使用当前：

  1. 每个用户的盐
  2. 来自系统哈希的盐
  3. 用户密码、用户盐和系统盐的哈希组合
  4. SHA-512 crypt() 或 bcrpyt() 类
  5. 动态加盐？主意？
4

3 回答 3

1

你这样做是不对的。

我认为您缺少有关重新散列密码的关键事实。为此，您必须以可恢复的形式存储它。因此，如果系统受到威胁，则会产生更大的安全风险。

这是我要做的：

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

您也可能受益于阅读：Properly Salting Passwords, The Case Against Pepper。

于 2012-06-09T10:04:55.947 回答
0

改变盐并没有改善任何东西。

关键是：您总是需要将盐和散列一起存储在某个地方，因为当您将密码输入与散列进行比较时，您需要对输入进行散列 - 很明显，对吧？

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

一个更好的方法是通过使用 1000-10000 轮散列以及长盐来扩展散列（你可以轻松地使用 512 字节的盐）。这些是比做一些重新散列更好的提示。

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

于 2012-06-08T23:22:18.917 回答
0

Salt仅用于防止预计算攻击，例如彩虹表。因此，如果有人想暴力破解哈希，他们实际上必须在运行时一次计算一个。（而不仅仅是在预先计算的散列值的数据库中查找）

目前还不清楚您要解决的问题是什么。你只是说：

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

如果该问题是预计算攻击，那么只需使用普通盐即可。如果不是预计算攻击，那么 salt 几乎肯定是错误的解决方案。

于 2012-06-09T00:02:00.557 回答