From: Demian K. <dem...@vi...> - 2012-03-26 12:37:34
|
I like the idea of the two-step upgrade process, especially since there's no turning back once the unencrypted passwords are wiped out! As far as supporting both new and old authentication schemes, can't we just leave the empty password column in place to avoid the DB_DataObject errors? I don't think an unused database column is a significant burden in the interest of flexibility... and since VuFind 2.0 will be moving away from the DB_DataObject dependency, this problem may go away entirely with the new major release. (At the same time, the most likely resistance to forcing a migration to more secure passwords is that it limits the administrator's ability to recover or reset passwords; a tool in the Admin module could help with this, as could "forgot my password" functionality as suggested by VUFIND-296). - Demian > -----Original Message----- > From: Mark Triggs [mailto:ma...@di...] > Sent: Saturday, March 24, 2012 11:35 PM > To: vuf...@li... > Subject: [VuFind-Tech] Hashing passwords (VUFIND-340) > > Hi all, > > I've been looking into VUFIND-340 ("Improve password security") and have > started by improving the handling of account passwords. > > The approach I'm taking is to add an extra column ('encrypted_password') > to the user table that will ultimately supersede the current 'password' > column. Then, I modify Account.php to create and store hashed > passwords, and DatabaseAuthentication.php to check them. > > I'm wondering about the process for people migrating from the old > password scheme to the new one. Somewhere along the way, there will > need to be a migration script that creates hashes for all existing > passwords, populates the new 'encrypted_password' column, and blanks out > the old 'password' column. Or maybe this is two scripts: one that > generates the hashes and invites the user to test that logins look OK, > and another to do the destructive blanking step once all is confirmed. > > Is it realistic to assume that everyone will be happy to run such a > script as a part of upgrading, so that the new authentication code > doesn't have to worry about checking the 'password' column at all? I > had originally planned on supporting both old and new authentication > schemes in parallel so that people had a choice about whether or not to > switch, but DB_DataObject throws errors if the defined model refers to > columns that don't exist, so it seems like some sort of database > migration will be required no matter what. > > Any thoughts would be greatly appreciated :) > > Mark > > -- > Mark Triggs > <ma...@di...> > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |