将现有用户和密码迁移到新的 Symfony/sfDoctrineGuard 用户系统

发布于 2024-10-16 14:11:41 字数 868 浏览 1 评论 0原文

我有一个现有的、非基于框架的 PHP/MySQL 网站。它有一个简单的安全模型,带有一个包含用户名和散列(MD5)密码的用户表。

我目前正在开发该网站的“版本 2”,这次使用 Symfony 和 Doctrine。新版本运行良好,我正在使用 sfDoctrineGuard 插件进行用户管理。

我希望以最少的麻烦将现有用户迁移到新应用程序,并保留他们现有的用户名和密码。不过,我的主要问题是我想更改我正在使用的密码哈希。

当前站点使用密码的未加盐 MD5 哈希值*。我已经弄清楚如何将用户迁移到 Symfony/sfDoctrineGuard,同时维护现有算法(通过为 unsalted MD5 提供我自己的“算法”函数。)但是 unsalted md5 显然并不理想。

所以 - 我的问题是,鉴于我可以使用自定义纯 MD5 密码哈希算法成功将一堆用户迁移为 sfDoctrineGuard 用户,有什么方法可以转换这些用户,以便他们使用标准的加盐 SHA1 sfDoctrineGuard 算法?

我认为我只能在每个用户登录时为每个用户执行此操作,因为这是我唯一一次拥有用户的明文密码以进行重新哈希。我想我需要做的是在“此用户刚刚使用此密码成功登录”点处进行挂钩,这样我就可以将用户的算法、盐和密码设置为新的 SHA1 系统,并将用户保存回数据库,而他们甚至不知道。

我已经进行了一些研究,但我无法找到一种方法来在正确的位置覆盖或挂钩 sfDoctrineGuard (特别是 sfGuardSecurityUser ,我认为?)登录系统。嗯,不是没有修改实际的插件文件,这看起来很邪恶。

有 Symfony/sfDoctrineGuard 专家能给我指出正确的方向吗?

*别那样看着我,这是我的第一个网站!至少我没有将它们存储为明文......

I have an existing, non-framework-based PHP/MySQL website. It has a simple security model, with a users table with usernames and hashed (MD5) passwords.

I'm currently working on "version 2" of this site, this time using Symfony, with Doctrine. The new version is working fine, and I'm using the sfDoctrineGuard plugin for my user management.

I'd like to migrate my existing users into the new app with the minimum of fuss, retaining their existing usernames and passwords. My main problem, though, is that I'd like to change the password hash I'm using.

The current site uses unsalted MD5 hashes of the passwords*. I've already figured out how to migrate users to Symfony/sfDoctrineGuard while maintaining the existing algorithm (by providing my own "algorithm" function for unsalted MD5.) But unsalted md5 obviously isn't ideal.

So -- my question is, given a bunch of users that I can successfully migrate into sfDoctrineGuard users with my custom plain-MD5 password hashing algorithm, is there any way I can then transform those users so they use the standard, salted SHA1 sfDoctrineGuard algorithm?

I figure I'll only be able to do this per-user as each user logs in, as that's the only time I'll have the user's plaintext password for re-hashing. I guess what I need to do is hook into something at the "this user just successfully logged in with this password" point so I can then set the user's algorithm, salt and password to the new SHA1 system, and save the user back to the database without them even knowing about it.

I've dug around a bit and I can't figure out a way to override or hook into the sfDoctrineGuard (specifically sfGuardSecurityUser, I think?) login system at the right point. Well, not without hacking around with the actual plugin files, which seems evil.

Can any Symfony/sfDoctrineGuard experts out there point me in the right direction?

*Don't look at me like that, it was my first website! And at least I didn't store them plaintext...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

风和你 2024-10-23 14:11:42

您有很多选择来解决您的问题。

您可以重载或更改 sfDoctrineGuardPlugin 中的几乎所有内容。

如果您需要更改 sfGuardSecurityUser 中的某些内容,则可以在应用程序的 User 类(实际上扩展了 sfGuardSecurityUser)中进行操作。

还可以重载默认放入 lib/model/doctrine/sfDoctrineGuardPlugin 目录中的模型类。

您也可以扩展默认保护架构。例如,您可以添加一个字段,告诉您用户是否更改了密码,如果没有更改则更新密码。

最后,您可以实现自定义密码检查和设置算法:
http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin?tab=plugin_readme (滚动到“使用外部方法检查用户密码”和“更改用于存储密码的算法”)。

You have plenty of options to solve your issues.

You're able to overload or change almost everything in sfDoctrineGuardPlugin.

If you need to change something in sfGuardSecurityUser than you can do it in your application's User class (which actually extends sfGuardSecurityUser).

It's also possible to overload model classes which are by default put into lib/model/doctrine/sfDoctrineGuardPlugin directory.

You can extend default guard schema as well. You could for example add a field telling you if user changed the password and update it if he didn't.

Finally you're able to implement your custom password checking and setting algorithm:
http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin?tab=plugin_readme (scroll to "Check the user password with an external method" and "Change the algorithm used to store passwords").

灼痛 2024-10-23 14:11:42

感谢库巴,他为我指明了正确的方向。

为了帮助其他想要做类似事情的人,这就是我所做的。

首先,我将现有用户(使用从旧数据库转储的文本文件中的固定负载)迁移到我的数据库中。我使用了一种自定义算法,该算法在数据加载期间使未加盐的 MD5 密码保持不变(称为 UniqueSentence::unsaltednotransform)。这为 sf_guard_user 中的用户提供了“密码”中的旧密码哈希值和“算法”中的“UniqueSentence::unsaltednotransform”。 (您同样可以直接将行迁移到表中,我只是发现将我的行作为固定装置很方便。)

然后我在 /lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php 中添加了自己的自定义 checkPassword 函数,如 如您所见

class sfGuardUser extends PluginsfGuardUser
{
  public function checkPassword($password)
  {
    if ($this->getAlgorithm() == 'UniqueSentence::unsaltednotransform') {
      // Our password has been set by a fixture load that left it in its
      // original state from the old system, an unsalted MD5.

      // Has the user got the right password?
      if (md5($password) != $this->getPassword()) {
        return false;
      }
      // Yes. So, now we re-set the password.
      $this->setSalt(''); // An empty salt will be regenerated
      // Use a smarter algorithm
      $algorithm = sfConfig::get('app_sf_guard_plugin_algorithm_callable', 'sha1');
      $this->setAlgorithm($algorithm); 
      $this->setPassword($password);
      // Could just return true here, but dropping through to the usual
      // method means that if we've broken something, we'll know sooner 
      // rather than later.
    }
    // Just pass the call onto the usual method.
    return parent::checkPasswordByGuard($password);
  }
}

,这非常简单 - 如果它检测到用户使用旧密码算法,它会使用旧算法验证密码,然后,如果它是正确的密码,它将算法更改为 SHA1,然后重新-设置密码(首先将盐设置为空,以便它也重新生成。)然后它只是直接使用基类中的标准 checkPassword() 。

这似乎工作成功——如果我以迁移的用户身份登录,它的工作方式就像普通用户一样,但如果我随后检查数据库,它们的算法、盐和散列密码已按预期更新。

Thanks to kuba, who pointed me in exactly the right direction.

To help anyone else out who was looking to do something like this, here's what I did.

First, I migrated my existing users (using a fixture load from text files dumped from the old database) into my database. I used a custom algorithm which left my unsalted MD5 passwords unchanged during the data-load (called UniqueSentence::unsaltednotransform). This gave me users in sf_guard_user with the old password hashes in 'password' and 'UniqueSentence::unsaltednotransform' in 'algorithm'. (You could equally just migrate the rows into the table directly, I just find it convenient to have mine as fixtures.)

I then added my own custom checkPassword function in /lib/model/doctrine/sfDoctrineGuardPlugin/sfGuardUser.class.php, as follows:

class sfGuardUser extends PluginsfGuardUser
{
  public function checkPassword($password)
  {
    if ($this->getAlgorithm() == 'UniqueSentence::unsaltednotransform') {
      // Our password has been set by a fixture load that left it in its
      // original state from the old system, an unsalted MD5.

      // Has the user got the right password?
      if (md5($password) != $this->getPassword()) {
        return false;
      }
      // Yes. So, now we re-set the password.
      $this->setSalt(''); // An empty salt will be regenerated
      // Use a smarter algorithm
      $algorithm = sfConfig::get('app_sf_guard_plugin_algorithm_callable', 'sha1');
      $this->setAlgorithm($algorithm); 
      $this->setPassword($password);
      // Could just return true here, but dropping through to the usual
      // method means that if we've broken something, we'll know sooner 
      // rather than later.
    }
    // Just pass the call onto the usual method.
    return parent::checkPasswordByGuard($password);
  }
}

As you can see, it's quite simple -- if it detects a user that has the old password algorithm, it validates the password using the old algorithm, and then, if it's the right password, it changes algorithm to SHA1, and re-sets the password (setting the salt empty first so it's also regenerated.) Then it just drops through to using the standard checkPassword() in the base class.

This seems to work successfully -- if I log in as a migrated user, it works just like a normal user, but if I check the database afterwards, their algorithm, salt and hashed password have been updated as expected.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文