mirror of
https://github.com/opensolutions/ViMbAdmin.git
synced 2026-04-26 00:36:00 +03:00
[GH-ISSUE #20] mailbox password change (from user) fails #18
Labels
No labels
bug
feature
feature
improvement
improvement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ViMbAdmin-opensolutions#18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vogan on GitHub (Jun 24, 2012).
Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/20
When an user wants to update the mailbox password, there is always the error: "Invalid username or password." thrown.
I compared the values of the stored and the hashed current password: these are not the same. I'm pretty sure the password is correct, the mail stack accepts it and its stored with KeepassX.
I use ViMbAdmin version 2.2.1, Password_Scheme is "dovecot:SSHA512"
@barryo commented on GitHub (Jun 25, 2012):
This works for me (tested password change and verified results).
The code is really simple - see application/controllers/AuthController.php:229 (changePasswordAction())
If you can confirm it is not working with a known good password, please stick a few die() commands in the function and see if you can prove / find an issue.
As it works for me, for now at least, I am marking as closed.
@vogan commented on GitHub (Jun 25, 2012):
As I mentioned in my post above, I have already been able to spot the problem in the AuthController. The passwort hash generated from the backend differs from the hash in the database.
With the password scheme "dovecot:SSHA512" the backend function hashPassword (Mailbox.php, Line 90) delegates the job to ViMbAdmin_Dovecot::password() in Line 94. In Dovecot.php, Line 74 the programm "doveadm pw" (or whatever you configured) is called.
If you do so, with the password "test" you'll always get another response. I'm pretty sure, that's because of the salt that is generated by "doveadm". See for yourself, run
doveadm pw -s SSHA512 -p test
a several times.
@woolfg commented on GitHub (Jul 2, 2013):
I can reproduce this bug when using dovecot:SSHA512 - the hash check function has to use the command "doveadm pw -t hash" to verify the password as it is only possible to verify the password if the salt is known which was used to hash the password.
@malteo commented on GitHub (Sep 3, 2013):
I can confirm the bug using "dovecot:SHA512"
@aewne commented on GitHub (Sep 5, 2013):
Just bumped into this issue myself. Also using SHA512.
@TinkerFu commented on GitHub (Sep 21, 2013):
Same issue. Using dovecot:SHA512-crypt
@dxtr commented on GitHub (Sep 23, 2013):
I guess I'll jump on the bandwagon. I am also using dovecot:SHA512-crypt
@ghost commented on GitHub (Feb 18, 2014):
It seems the code could be easily modified to support SHA512-CRYPT, etc., basically as woolfg indicated, the -t option needs to be passed to doveadm when verifying that the old password matches. This can be tested easily by generating a password:
/usr/bin/doveadm pw -p k3nd1ll@1 -s SHA512-CRYPT
{SHA512-CRYPT}$6$4otqbbg4cfyqfq33$xmlM778SSuUGfcp8j.Rxt6bmUC.59LNNtTiDo1qBylBnHk8raahJTP8dTWRYf1opJc7P.KGZbYJsdi.GFiPp50
And then verifying it:
/usr/bin/doveadm pw -t '{SHA512-CRYPT}$6$4otqbbg4cfyqfq33$xmlM778SSuUGfcp8j.Rxt6bmUC.59LNNtTiDo1qBylBnHk8raahJTP8dTWRYf1opJc7P.KGZbYJsdi.GFiPp50'