Password decryption failing
brandon.dixon - September 26, 2009 - 05:18
| Project: | XMPP Framework |
| Version: | 6.x-2.1 |
| Component: | XMPP-User |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Passwords are encrypted when a user uses the password field located within their account page. This encryption is basically a string translation that is successful in converting the user's password to a protected string when storing, but never decrypts when pulling back out of the database. This has been tested and verified on the current release of the module. I was able to successfully fix the error for the time being by commenting out the encryption/decryption portions of the code and merely storing and returning the password in the clear as is. I plan to spend a little more time trying to figure out why the decryption aspect is not working as intended. I will update the bug with any more details.
#1
is this the reason for this error message:
"Wrong combination Username / Password. Please re-login to the site for synchronization" ???
#2
Most likely a wrong username or password, for every update to that table there is an encrypt for the password.
For every time the password is needed there is a decrypt. Unless you have other alterations to the module this should not be failing at all
#3
I had no alterations, but I will check agaisnt the most recent revision. It took me a week to figure out that it was in fact the code and not my environment. Passwords were properly encrypted, but never descrypted like they should have been. I could see this by using Firebug and watching the password that was being submitted. In all cases of failure I saw that the password being sent to the server was not the user's password, but instead the "encrypted" version. I will check the latest release as soon as I can.
#4
Are you guys getting this issue resolved any soon, I think I'm affected as well as result XWChat can't connect because of this error: Wrong combination Username / Password (While the xmpp rooster works finely). Please re-login to the site for synchronization. Practically this makes the whole module useless, would be nice to have just even a workaround for the time being... Thanks.
#5
This code is written with ldap in mind and works without issue.
For the non ldap portion i would suggest you show the password field on the user edit form and then enter the password in there.
That will then save the password and it will be utilized correctly.
also make sure the save password on login is not checked.
#6
Ok i tested a bit more in "LDAP" environment using the same drupal login password everything works... yet if I try to save a different password and not use the drupal login one, the error returns.
#7
Toren - If you want a work around then shoot me an email - brandon.s.dixon@gmail.com. Feel free to hit me up via Google Talk as well. I am running an LDAP environment and noticed the issue. The best way to troubleshoot the problem and see if its related to passwords not being decrypted is to use firebug and watch the authentication take place. You should see your username and password passed in the clear (depending on your configuration).
#8
For me, the problem is that the value of $account->xmpp_user->password is not encrypted.
I'm trying to figure out why, but that's causing me problems.
#9
Here's the fix:
function xmpp_user_update($edit, $account, $category = NULL) {
...
...
elseif (isset($edit['xmpp_user']['password']) && !is_null($edit['xmpp_user']['password']) && drupal_strlen($edit['xmpp_user']['password'])) {
$password = xmpp_user_encrypt_password($edit['xmpp_user']['password']);
db_query("UPDATE {xmpp_user} SET jid = '%s', resource = '%s', password = '%s' WHERE uid = %d", $edit['xmpp_user']['jid'], $resource, $password, $account->uid);
$edit['xmpp_user']['password'] = $password; // <----------- store the encrypted password
}
......
......
#10
Can you put the fix into a cvs diff patch based off the current branch then i will be able to look at it and determine if it wont break the functionality which currently works on all 100+ sites it is deployed on our end.