But currently everybody's password is "password" because the authentication system isn't built out nicely yet.
I've been contemplating how to do it generically, so plugins can just declare what sort of authentication world they're living in, and DJabberd can then advertise on to the client the right auth modes which'll work with the underlying authn plugin.
In summary, I think the major worlds are:
1) The easiest, whereby client provides plaintext password (over SSL), and plugin can check it. A lot of times the client can provide the cleartext but the server doesn't know the cleartext because it's protected by, say, LDAP, or stored as only a digest on the server. Disadvantage is this requires SSL, but this is where a lot of auth plugins would have to go. And once client provides plaintext, DJabberd can then do whatever auth foo is required to test it.
2) But if the server knows the cleartext and can declare that, and provide the cleartext to Djabberd on request, a lot more auth options are available. (challenge-response stuff)
3) Finally, if user won't provide cleartext (no SSL) and server can't fetch the cleartext, then you hope there's an upstream auth provider that speaks SASL, and you just proxy SASL challenge/responses back and forth. A lot of LDAP servers let you speak SASL. I think ours at work will, but it's disabled? So I think I'll need to make our authn plugin do option 1) above, where we get plaintext passwords over SSL and then try to bind to the LDAP server. And that's what's inspired this post: DJabberd currently doesn't do SASL, and doesn't ask for cleartext passwords ever (when it advertises auth methods).
But too tired. Just dumping thoughts.
What other auth types am I missing that don't fit into those 3 categories?