Hi, I have a current auth database using mysql with a "password"
column
in plain text. The config has "default_pass_scheme = PLAIN" specified
In preparation for a more adaptable system I changed a password entry
from "asdf" to "{PLAIN}asdf", but now auth fails. Works
fine if I
change it back to just "asdf". (I don't believe it's a caching
problem)
What might I be missing? I was under the impression that the password
column can include a {scheme} prefix to indicate the password scheme
(presumably this also means a password cannot start with a "{"?). Is
this still true when using mysql and default_pass_scheme ?
Thanks for any hints?
Ed W
On 24/01/2012 22:06, Ed W wrote:> Hi, I have a current auth database using mysql with a "password" > column in plain text. The config has "default_pass_scheme = PLAIN" > specified > > In preparation for a more adaptable system I changed a password entry > from "asdf" to "{PLAIN}asdf", but now auth fails. Works fine if I > change it back to just "asdf". (I don't believe it's a caching problem) > > What might I be missing? I was under the impression that the password > column can include a {scheme} prefix to indicate the password scheme > (presumably this also means a password cannot start with a "{"?). Is > this still true when using mysql and default_pass_scheme ?Hmm, so I try: # doveadm pw -p asdf -s sha256 {SHA256}8OTC92xYkW7CWPJGhRvqCR0U1CR6L8PhhpRGGxgW4Ts I enter this hash into my database column, then enabling debug logging I see this in the logs: Jan 24 22:40:44 mail1 dovecot: auth: Debug: cache(demo at mailasail.com,1.2.24.129): SHA256({PLAIN}asdf) != '8OTC92xYkW7CWPJGhRvqCR0U1CR6L8PhhpRGGxgW4Ts=' Jan 24 22:40:44 mail1 dovecot: auth-worker: Debug: sql(demo at blah.com,1.2.24.129): query: SELECT NULLIF(mail_host, '1.2.24.129') as proxy, NULLIF(mail_host, '1.2.24.129') as host, email as user, password, password as pass, home userdb_home, concat(home, '/', maildir) as userdb_mail, 200 as userdb_uid, 200 as userdb_gid FROM users WHERE email = if('blah.com'<>'','demo at blah.com','demo at blah.com@mailasail.com') and flag_active=1 Jan 24 22:40:44 mail1 dovecot: auth-worker: sql(demo at blah.com,1.2.24.129): Password mismatch (given password: {PLAIN}asdf) Jan 24 22:40:44 mail1 dovecot: auth-worker: Error: md5_verify(demo at mailasail.com): Not a valid MD5-CRYPT or PLAIN-MD5 password Jan 24 22:40:44 mail1 dovecot: auth-worker: Error: ssha256_verify(demo at mailasail.com): SSHA256 password too short Jan 24 22:40:44 mail1 dovecot: auth-worker: Error: ssha512_verify(demo at mailasail.com): SSHA512 password too short Jan 24 22:40:44 mail1 dovecot: auth-worker: Warning: Invalid OTP data in passdb Jan 24 22:40:44 mail1 dovecot: auth-worker: Warning: Invalid OTP data in passdb Jan 24 22:40:44 mail1 dovecot: auth-worker: Debug: sql(demo at blah.com,1.2.24.129): SHA256({PLAIN}asdf) != '8OTC92xYkW7CWPJGhRvqCR0U1CR6L8PhhpRGGxgW4Ts=' Forgot to say. this is with dovecot 2.0.17 Thanks for any pointers Ed W
On 24/01/2012 22:06, Ed W wrote:> Hi, I have a current auth database using mysql with a "password" > column in plain text. The config has "default_pass_scheme = PLAIN" > specified > > In preparation for a more adaptable system I changed a password entry > from "asdf" to "{PLAIN}asdf", but now auth fails. Works fine if I > change it back to just "asdf". (I don't believe it's a caching problem) > > What might I be missing? I was under the impression that the password > column can include a {scheme} prefix to indicate the password scheme > (presumably this also means a password cannot start with a "{"?). Is > this still true when using mysql and default_pass_scheme ?Bahh. Partly figured this out now - sorry for the noise - looks like a config error on my side: I have traced this to my proxy setup, which appears not to work as expected. Basically all works fine when I test to the main server IP, but fails when I test "localhost", since it triggers me to be proxied to the main IP address (same machine, just using the external IP). The error seems to be that I set the "pass" variable in my password_query to set the master password for the upstream proxied to server. I can't actually remember now why this was required, but it was necessary to allow the proxy to work correctly in the past. I guess this assumption needs revisiting now since it can't be used if the plain password isn't in the database... For interest, here is my auth setup: password_query = SELECT NULLIF(mail_host, '%l') as proxy, NULLIF(mail_host, '%l') as host, \ email as user, password, \ password as pass, \ home userdb_home, concat(home, '/', maildir) as userdb_mail, \ 1234 as userdb_uid, 1234 as userdb_gid \ FROM users \ WHERE email = if('%d'<>'','%u','%u at mailasail.com') and flag_active=1 "mail_host" in this case holds the IP of the machine holding the users mailbox (hence it's easy to push mailboxes to a specific machine and the users get proxied to it) Sorry for the noise Ed W