Migrating Existing Users and Passwords to new Symf

问题:

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...}

回答1:

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").

回答2:

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.