aes password storage fails for ldap module authenticated users

Sorry for taking so long to respond to this, I'll have a look at it tomorrow if I can find the time. But - without looking at any code - I'd say this smells like an issue with the ldap module and not with aes, but we'll see.

I've had a look at it now and I'm pretty sure it's an issue with the ldap module. If the ldapauth module would set the 'pass' var in the user-object on line 771 in ldapauth.module (version 6.1-dev-20080405 - in the call to user_module_invoke) I think that would fix the problem. I can't test this though since I don't have an ldap server available.

So you see, I could 'fix' this problem in my module like you did, but that would be fixing it in the wrong place, and I'd rather not create a new release just to compensate for this flaw in another module - which would alert everyone using this module that there is a new version available - meaning a lot of people using this module would have to go through upgrading it for no reason at all if they're not also using the ldap module.

I hope you understand my reasoning and thanks for reporting it anyway.

Very similar to the patch in comment #3 but updated for version 1.4. The issue still exists in v1.4.

$edit does not contain the password.
$_POST contains the password in plain-text.
$account contains the password in md5.

So, we need to pass $_POST['pass'] to aes_encrypt().

Oh okay, I see what you're saying about ldapauth. On line 151, it removes $edit['pass'].

Perhaps we just accept that that module isn't going to change so we add a if module_exists('ldapauth') and act accordingly?

The root of the problem is that ldapauth sets a random password for accounts that are created from a first-time login. That provides aes with a strange password. Explains why $_POST['pass'] works instead of $edit['pass']. This only happens if sync passwords is turned off.

Thanks mike! Good job getting to the root of the problem! I'm guessing that this is still something which could/should be fixed in the ldap module, but since I'm getting older and less puristic and more in tune with the fact that we're living in an imperfect world, I'm willing to fix it like you suggest in this module :)

I'll do it when I feel like it though, because it's not a major issue I think (don't think that very many people use this in conjunction with ldap and sync passwords off), and I have a lot to do on my real job.

Wait a bit because I'm trying to figure out a better solution than using $_POST. That's never a good thing to do.

Great! Glad to have you working on it.

Reworked hook_user a bit. Made things much easier to read with a switch statement instead of a bunch of ifs. Also, I recommend you check out the coding standards section in the module maintainers guides to keep the code looking clean.

I set all the encrypting to happen in hook_user on $op == update, insert, and login. This should work fine with or without ldap. If ldapauth sets a random password on user insert, it won't matter because the user is logged in right after with the right password, so aes will pick it up.

Mike, how do you feel about taking over this module? It hasn't had very many issues or support requests in the past, and I'm guessing it probably won't in the future either. But I just don't feel like spending my free time on it anymore, no matter how rarely I actually have to do something.

I'll think about it. I'm not too knowledgeable with encryption and aes.

mikesteffs patch doesn't really change anything from what I can tell, it just moves things around a bit, so I'm guessing this bug still remains? Not sure what to do with this

@mikestefff

I have recently taken over the AES module from easyfit. I am looking to provide support to the issue queue and would like to see if you ever found a solution to aes + ldap integration.

For now, I am marking this as postponed until I hear back from you. Thanks.