On 2008-05-12 at 21:46 +0200, Thomas Baumann wrote:
> I hope sb can help me. I've got problems with smtp_auth and cram_md5.
>
> In my MYSQL database the passwords are stored as a md5_hex hash, caculated by
That's the problem. In short: you can't.
CRAM-MD5 fundamentally needs either the plaintext password available to
the server, or a special intermediate value, an HMAC-MD5 context based
on the password, which is *not* the same as the md5_hex hash.
You can't use CRAM-MD5 with md5-stored passwords.
Mostly, if the server keeps the password encrypted in a strong form
that's not special to a particular authentication protocol (eg, storing
the relevant MD5 context needed for CRAM-MD5) then you need the
authentication protocol to have the client send the password to the
server. If you don't want the client to send the password, then the
server needs access to the password.
If you want to not have the client send the full password but don't want
the password stored "clear" on the server, then your main real-world
options are not really suitable for use here:
* Store the MD5 context, used CRAM-MD5, be tied into MD5 in ways which
are not so good, when MD5 is losing viability; this is probably not a
good step forward.
* Use SRP,
http://srp.stanford.edu/ which has limited client and server
support so will not buy you much, unless you control all the clients
and are willing to mess with using experimental SASL profiles and
modules; again, the server-side stored data is protocol-specific.
Neither is really solid for new production-quality deployment; it's part
of why TLS is so popular.
If you want this just for personal use, then it's possibly worth hacking
on SRP support, using the cyrus_sasl driver and finding an SRP plugin
for that. If it's for an organisation's internal authentication, then
you can move the password out of the SQL database and into a KerberosV
server, which you then lock down tightly (since it stores cleartext
passwords) and the servers never get to see the plaintext password, only
tokens.
-Phil
