Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login fails with Dovecot 2.3.13 / Debian Bullseye #576

Closed
svenseeberg opened this issue Dec 26, 2021 · 2 comments
Closed

Login fails with Dovecot 2.3.13 / Debian Bullseye #576

svenseeberg opened this issue Dec 26, 2021 · 2 comments

Comments

@svenseeberg
Copy link
Contributor

svenseeberg commented Dec 26, 2021

I upgraded my mail server to Debian Bullseye and now accounts can not log in on Postfixadmin 3.3.10. Dovecot. The credentials verify with doveadm auth test user@example.com SECRET. Also, IMAP login etc works without issues. So its a thing between Postfixadmin and Dovecot.

The Apache2 error log has the following entries:

[Sun Dec 26 20:44:46.750491 2021] [php7:notice] [pid 2142068] [client IP] Failed to read password from /usr/bin/doveadm pw -r 10 ... stderr: Fatal: Missing {scheme} prefix from hash\n, password: , method: BLF-CRYPT , referer: https://example.com/admin/users/login.php
[Sun Dec 26 20:44:46.750609 2021] [php7:notice] [pid 2142068] [client IP] Error trying to call pacrypt(), referer: https://exmple.com/admin/users/login.php
[Sun Dec 26 20:44:46.750633 2021] [php7:notice] [pid 2142068] [client IP] Exception: /usr/bin/doveadm pw -r 10 failed, see error log for details in /opt/postfixadmin/functions.inc.php:1060\nStack trace:\n#0 /opt/postfixadmin/functions.inc.php(1275): _pacrypt_dovecot()\n#1 /opt/postfixadmin/model/Login.php(49): pacrypt()\n#2 /opt/postfixadmin/public/users/login.php(56): Login->login()\n#3 {main}, referer: https://example.com/admin/users/login.php

I added the full command for output that fails:

/usr/bin/doveadm pw -r 10 '-s' BLF-CRYPT -t 'def'

So as far as I can tell https://github.com/postfixadmin/postfixadmin/blob/master/model/Login.php#L52 checks if the password validation works in general, right?

So I played around with the scheme and -s flag:

$ /usr/bin/doveadm pw -r 10 -s BLF-CRYPT -t 'def'
Enter password to verify: 
Fatal: Missing {scheme} prefix from hash
$ echo $?
75

$ /usr/bin/doveadm pw -r 10 -s BLF-CRYPT -t '{BLF-CRYPT}def'                                                         
Enter password to verify: 
Fatal: reverse password verification check failed: Password is not blowfish password
$ echo $?
75

# password asdf
/usr/bin/doveadm pw -r 10 -s BLF-CRYPT -t '$2y$05$wmel.60XmC5X3nfzcJ96ceJsThaMMF7T.0iLw9gdotmfP0kiJxzju'
Enter password to verify: 
Fatal: Missing {scheme} prefix from hash
$ echo $?
75

/usr/bin/doveadm pw -r 10 -s BLF-CRYPT -t '{BLF-CRYPT}$2y$05$wmel.60XmC5X3nfzcJ96ceJsThaMMF7T.0iLw9gdotmfP0kiJxzju'
Enter password to verify: 
{BLF-CRYPT}$2y$05$wmel.60XmC5X3nfzcJ96ceJsThaMMF7T.0iLw9gdotmfP0kiJxzju (verified)
$ echo $?
0

/usr/bin/doveadm pw -r 10 -t '{BLF-CRYPT}$2y$05$wmel.60XmC5X3nfzcJ96ceJsThaMMF7T.0iLw9gdotmfP0kiJxzju'
Enter password to verify: 
{BLF-CRYPT}$2y$05$wmel.60XmC5X3nfzcJ96ceJsThaMMF7T.0iLw9gdotmfP0kiJxzju (verified)
$ echo $?
0

man 1 doveadm-pw tells us:

       -s scheme
              The password scheme which should be used to generate the hashed password.  By default the CRAM-MD5 scheme will be used.  It is also possible to append an encoding suffix to the scheme.   Supported encoding suffixes are: .b64, .base64 and .hex.
              See also http://wiki2.dovecot.org/Authentication/PasswordSchemes for more details about password schemes.

Now I'm wondering if Dovecot is not accepting/interpreting its -s flag correctly or behaving as expected.

I'm currently trying to add a workaround for the time being.

@svenseeberg
Copy link
Contributor Author

svenseeberg commented Dec 26, 2021

I was playing around with the source code and suddenly it works. I reverted all my changes - mostly debug output - and it continues to work. I have no idea why / what changed. But I think this issue can be considered closed.

@DavidGoodwin
Copy link
Member

I'll assume this is probably related to file permissions - see also : #379

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants