On Tue, 2010-04-27 at 12:50 +1200, Jim Cheetham wrote:
> Quoting Ron White (from 24/04/10 03:01):
> > server_condition = ${if crypteq {$3}{\{whateva\}${lookup mysql{ SELECT
> > userpassword FROM mailusers WHERE some_condition.....\}}}{yes}{no}}
>
> You have an extra unwanted \ in there at the end of the mysql section.
>
> I'm assuming that your database lookup returns just
> "encrypted-password". Exim is sort-of expecting it to return
> "{encryption-scheme}encrypted-password" (i.e. the name of the encryption
> scheme used first, in curly brackets; and then the actual encrypted
> data), and most of the confusion above is coming because it doesn't, and
> the syntax for fixing up this "problem" is confusing.
>
> How it all works :-
>
> The authentication session provides an actual password (it was lightly
> encoded with base64 during the SMTP session, but this has been taken
> care of automatically). Under PLAIN authentication, $3 will contain the
> actual user password.
>
> The ${lookup mysql{...}} returns "encrypted-password", because the
> database should not be storing the password itself. Please don't store
> plain passwords in a database ... :-|
>
> Therefore in order to compare the password with the encrypted password,
> we have to say what encryption scheme the database is using -- md5,
> sha1, whatever. We cannot decrypt what the database returns, so we must
> encrypt the password -- but the difference is invisible to us, Exim does
> the right thing.
>
> In order to encrypt the password, we need to tell crypteq which
> encryption scheme to use -- "sha1" normally, "whateva" in your example
> above. I hope you've compiled in support for the "whateva" scheme! We
> need to tell crypteq explicitly what scheme we're using, it cannot guess
> by looking at the values. Exim is expecting "{scheme}data", but our DB
> isn't returning that ...
>
> Also, crypteq's *syntax* is confusing because it doesn't read like
> "encrypt the password with 'whateva' and compare that to what's in the
> database", it reads "compare the password with the 'whateva'-encrypted
> data from the database".
>
> And, for good measure, the way you say "whateva" demands curly brackets,
> which are *not* part of the command syntax, and therefore need to have
> backslashes in front of them ...
>
> crypteq takes two strings, the unencrypted password in one, and the
> encrypted password PLUS the encryption scheme name in the second. We
> need to explicitly say \{whateva\} in front of the SQL lookup.
>
> crypteq {$3}{\{whateva\}${lookup ...}}
>
> ${if} takes three values; the query (the entire crypteq thing from
> above), and the two results.
>
> server_condition = ${if crypteq {$3}{\{whateva\}${lookup ...}}{yes}{no}}
>
> read more about crypteq:
> http://www.exim.org/exim-html-4.40/doc/html/spec_11.html
>
> -jim
>
Thank you Jim. That makes it clearer. I've got it working with PLAIN and
LOGIN now, but not using crypteq - I did it like this thanks to a list
responder:
plain:
driver = plaintext
public_name = PLAIN
server_condition = ${lookup mysql{SELECT 1 from mailusers WHERE
email='${quote_mysql:$2}' AND userpassword = md5('${quote_mysql:$3}')
and outbound = 1}}
server_set_id = $1
login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = ${lookup mysql{SELECT 1 from mailusers WHERE
email='${quote_mysql:$1}' AND userpassword = md5('${quote_mysql:$2}')
and outbound = 1}}
server_set_id = $1
Fully understand your point about keeping plaintext passwords in a
database - it's something I've never personally done. It crossed my mind
that this would be very interesting in supporting CRAM-MD5 mind you. All
things considered I'm probably not going to support it and I'll stick
with LOGIN/PLAIN and TLS.
