Personally I feel the best security is to simply use an \"irc set of passwords\" that are not used fr anything else .. after all .. it IS just IRC. If you link services to a local ircd to services and have all servers use ssl connections, then there is no need for any other type of encrypted passwords in the data stream as the only place that passwords can be sniffed is as root on a box that hosts an IRCD, in which case ssl connected servers won\'t mean a hill of beans as packets can be sniffed after they are decrypted. Users can also connect with ssl enabled clients to said ssl enabled ircds and all traffic to and from services would then be encrypted. Such technologies already exist so no one needs to code yet another method of doing the same thing.
That makes sense, but your audience is an inherently paranoid bunch: IRC Admins.
To continue this in a philosophical manor, I really dont see this as a method that will be used by users as much as it would by bots. Most people running eggdrops and various other bots prolly arn't running stunnel. and they are often on shared shell host boxes. So you have an insecure connection (without patching with code that has proved to be unstable, to create secure ones), on an untrusted box (in the network sense. The file security of the box can be enforced by the user), and a nickserv account with (unboutedly) some privilege in services. There, in that limited, but all too common, circumstance lies a need.
now we can debate the merits and abundant flaws in running a bot with privileges to services (i reference chanserv mostly. a bot with operserv privs..well...the network that does that, deserves what it gets in my opinion), but users are going to do it anyways. Providing a mechanism for challenge based authentication will at least remove a portion of the 'untrusted box' problem.
That said, Im a paranoid freak, and I am all for multi-factor authentication wherever I can get it. If i could authenticate with a
YubiKey (This thing makes my mouth water its so cool), I would. I'm going to hold off on the module request for that for a while.