[Dovecot] multiple password schemes and sql?
Hello all.
Just about to migrate from courier to dovecot, and figured I would as well try and get this working so I could use non plaintext mechanisms as well.
I would like to offer at least: plain login digest-md5 cram-md5 and maybe more
Everything works but this and have a testdb in sql with passwords like userid, password
But get "Password query returned multiple matches" which indicates it doesnt try using any prefix and just get a hit on all "passwords" for that user.
Is there any variable I can use in the sql query to use an extra field that contains the password type?
plain and login should be stored in some crypted form, probably as md5 or sha256 hashes.
Thankful for any insight into this...
Hi again.
Ok, tested now with 1.1.2 and also a nightly build with 1.2-UNSTABLE to make sure it isnt too old.
password query to talk to database in dovecot-sql.conf is:
password_query = SELECT id as user, passwd as password FROM passwds WHERE id = '%u' AND model = '%m'
This constantly fails and %m is always empty according to sql logs. auth-worker is given the information about mechanism, so seems like the %m just isnt used?
Any ideas?
/Roger
Timo Sirainen wrote:
On Tue, 2008-08-26 at 13:42 +0800, R A wrote:
Is there any variable I can use in the sql query to use an extra field that contains the password type?
You could use %m which expands to the used mechanism name.
On Wed, 2008-08-27 at 14:58 +0800, R A wrote:
Hi again.
Ok, tested now with 1.1.2 and also a nightly build with 1.2-UNSTABLE to make sure it isnt too old.
password query to talk to database in dovecot-sql.conf is:
password_query = SELECT id as user, passwd as password FROM passwds WHERE id = '%u' AND model = '%m'
This constantly fails and %m is always empty according to sql logs. auth-worker is given the information about mechanism, so seems like the %m just isnt used?
Actually the problem was that auth-worker didn't know about the mechanism. This should fix it: http://hg.dovecot.org/dovecot-1.1/rev/3fcfe8d316b6
Works like a charm now!!
Just a thought though, as you have to store the password in the form {CRAM-MD5}xxxxxxxxx to actually get that and not the default_pass_sheme would it not be better to have an 'extra' field that could override default_pass scheme if it existed instead?
That way it would also be possible to have plaintext passwords with {} in them and not have to sanitize that.
Anyway, thank you for the quick fix...
-Roger
Timo Sirainen wrote:
Actually the problem was that auth-worker didn't know about the mechanism. This should fix it: http://hg.dovecot.org/dovecot-1.1/rev/3fcfe8d316b6
On Aug 28, 2008, at 6:05 AM, R A wrote:
Just a thought though, as you have to store the password in the form {CRAM-MD5}xxxxxxxxx to actually get that and not the
default_pass_sheme would it not be better to have an 'extra' field that could override default_pass scheme if it existed instead?
The {scheme}pass works with all passdbs, some of which don't have the
possibility of storing the scheme elsewhere. But of course this could
be done for SQL and others where it's possible, would just require
more code..
That way it would also be possible to have plaintext passwords with {} in them and not have to sanitize that.
For that it's possible to:
a) Use password_noscheme field (requires default_pass_scheme to be
PLAIN then)
b) Use the {plain} prefix - after that you're free to use { and }
characters in the password.
participants (2)
-
R A
-
Timo Sirainen