【发布时间】:2011-03-10 11:11:49
【问题描述】:
我想我在这里失去了我的弹珠......我的网站出现了一个问题,它随机停止接受登录。我现在已经能够追踪到 crypt() 的行为非常奇怪。
在我的数据库中,我有用户密码的加密版本 - 所以我们说 Og12345678。
当用户登录时,他们输入他们的密码,我从数据库中读取 salt,然后加密他们输入的内容并进行比较 - 通常这很有效。
所以我正在做 crypt($enteredPassword, $saltFromDb) - 在这种情况下,盐当然是 Og。通常对于给定的用户密码 crypt 工作正常。
当事情出错时(当他们出错时,这是一个永久性更改,直到我重新启动 Apache)我发现 crypt 开始为相同的输入返回一个不同的答案,使用相同的盐。
然而,它是一致的,即一旦系统出错,crypt 返回错误的答案,但它总是返回 same 错误的答案。页面的重复刷新显示相同的输出。同样的盐也出现在新的不正确的 crypt 结果中,所以并不是盐在某个地方丢失了。
如果我随后重新启动 Apache 并重新运行脚本而不做任何更改,那么来自 crypt 的结果就会恢复到应有的状态。
我很欣赏它不是最新的 PHP (5.2.8),但我会重视对此的任何看法,包括它是否是在更高版本中修复的已知错误(升级 PHP 并不是一项令人愉快的任务,因为有很多网站,其中一些仍在使用不幸的怪癖,每次升级都需要重新测试) - 如果它是一个已知的固定错误,那么显然我会尽快升级它,除此之外它可能更容易从外部外包地下室,因为我只使用它位于我网站的一个公共位置。
任何意见表示赞赏。
马特·佩德尔斯登
--- 更新:2011 年 3 月 11 日
更正先前给出的有关操作系统的评论... - 操作系统为 Windows Server 2008 SP1 64 位。道歉我应该仔细检查而不是假设我能记住!机器是戴尔 2950 8gb 内存,至强处理器。
我开始按照 Krtek 建议的思路思考 - 当系统出现问题时,如果我生成新的 crypt()(即一个非常简单的示例,我将变量设置为字符串,将其加密,然后与地穴) - 一切都很好。当我重新启动服务器时,它又回到了以前的计算。所以我肯定倾向于改变用于计算 crypt() 结果的算法...关于可能导致这种情况发生的任何想法?我打印出 CRYPT_STD_DES 等的值,它们在重新启动之间不会改变。
有人知道什么可能导致这种情况发生吗?
昨天一天内似乎发生了两次,最奇怪的是。
感谢到目前为止的回答。
--- 更新:2011 年 3 月 16 日
只是想提供另一个更新。
这仍在发生,仍然没有进一步了解原因。
如果将来有人遇到这种情况,我认为我的解决方案将是做一些讨厌的 hack,将所有 crypt() 执行推送到外部 C# 应用程序,并且不再依赖 PHP 来执行做他们。某处出了点问题,此时我能看到的唯一解决方案是将其从方程式中完全删除。
当然,如果它仍然发生,那也将很有趣! :)
谢谢大家。
【问题讨论】:
-
我认为这不太可能是您的问题,但我看到 PHP 文档中的建议 -- php.net/manual/en/function.crypt.php -- 是您应该将整个(加盐的)加密密码作为盐。
if (crypt($enteredPassword,$cryptedPasswordFromDB) == $cryptedPasswordFromDB) { ... }。关键似乎是 crypt() 可以从 $cryptedPasswordFromDB 确定正在使用的散列算法。同样,我怀疑这是否是您的问题的原因,但您可以试一试... -
是否有可能比脚本更改某些 php 配置导致 crypt 使用不同的哈希函数?就像@Gareth 所说的那样,从数据库传递完整的密码可以解决这个问题。
-
我开始按照 Krtek 建议的思路思考 - 当系统出现问题时,如果我生成新的 crypt()(即一个非常简单的示例,我将变量设置为字符串,crypt它然后与地穴进行比较) - 一切都很好。当我重新启动服务器时,它又恢复了工作。所以我肯定倾向于改变用于计算 crypt() 结果的算法......关于可能导致这种情况发生的任何想法?我打印出 CRYPT_STD_DES 等的值,它们在重新启动之间不会改变。