Provide some sort of core special modules which handle password encryption/verification. The current "MD5" implementation is an Epona legacy bastardization. If that encryption method were to be abstracted by making it a module, you could provide an easy migration path for current databases to more reliable, standardized encryption algorithms.
Each different algorithm would have its own module and each module would have its own unique identifier, including the module's version number. That identifier could be stored with each nick core and channel entry, thereby defining the encryption function used on that entry's password. If multiple encryption modules are loaded, provide a way to make one of them a default or "migrate-to" module so that as users identify with their passwords, they're verified using the encryption method currently stored in their entry, but get re-encrypted using the default module's encryption function.
Maybe even provide a notice from ChanServ when channel founders identify with NickServ, asking them to re-identify to their channels so that the channel database can get migrated more quickly as well.
While a migration is being done, include an easy way for admins to query OperServ in regards to statistics about the migration. Report a percentage of the database that isn't ecrypted using the default function and maybe even provide a list of channels and nick cores which haven't migrated yet.
The current password encryption implementation in the core uses a function that returns a 16 byte binary glob. That data is operated upon using string functions when reading and writing to the databases (SQL and FF). Since the data returned by the current encryption function may or may not contain null characters within (not just at the end), string functions will truncate those which do contain null characters. The database is written out to disk/SQL and services goes down (server reboot or whatever). When it's read back in, the password data which contained null bytes is truncated and no longer matches the hash when users try to log in. Examples of cleartext passwords which include null characters after encryption are: "bluefox" and "garfield" These and other passwords which end up containing null characters after encryption stop working after a services reboot. I filled out a
bug report, but it ended up just being closed with no resolution. Not quite sure why that happened.
It would be cool to have a way to migrate away from those encryption functions and toward ones that work on all passwords consistently.
