changePass passes hash not raw password

[Luke]

Alright I guess I'm going to have to post this in the feedback forum here.

Basically in IPB 3.0 there is a function you can add to your modules called "changePass". In han_login.php this is referenced as "new_pass", and no where does it mention it being md5'd. But if you do a search on every instance of "changePass" being called from han_login (usercpForums.php, details.php, lostpass.php, register.php, editform.php) they all md5 the password before passing it into this function.

The problem with this is you're assuming that the password is md5'd once before making any modifications. The authenticate function does NOT make this assumption, and is therefore inconsistent (it passes the raw password). In my case the server I'm trying to authenticate adds a salt to the end of the raw password before md5'ing it. Now I know this may seem "odd", but I have absolutely no control over how the passwords are hashed on this server. And as it is now, all I can do is authenticate... I can't update the password if it is changed, and I'm planning on making the forum handle all the account management stuff. If the password was going to be hashed first, wouldn't I want to do that myself?

I also hear it's the same way with converge.

Really need this changed. Can this please be updated in 3.1?

In the mean time I'll have to modify 3.0 until this gets changed. I don't think the areas that use han_login->changePass are hookable, but I may be wrong (I'll just change it on my copy until it's updated).

Also is there a way for when the user changes the password on the board to verify the old password with the login modules? (I haven't looked yet). I know in 2.3, for some reason, it was not there (although it was for converge). If this does exist, this needs to pass raw password as well.

[Mark]

Perhaps I'm misunderstanding what you mean, but can't use use memberSync?

[Luke]

The update password function in memberSync passes user id and password (presumably raw). But I need a packaged login module, and memberSync can be used for other purposes. It also doesn't help me that just the id is passed. I'd have to query for the member again if I were to use that. It can be used as a temporary thing, sure.

The update passwod function on the login module passes email and the hashed password. Two problem: My login module uses username, not email, so email is usless to me. The password is hashed, so I can't do anything with it.

I would like the login method be self contained within the login module. But it assumes I'm using email and the password is hashed once. It's not very friendly.

[Josh]

We've updated changePass to send the plain text password in 3.1 :)

[Luke]

We've updated changePass to send the plain text password in 3.1 :)

Awesome!

Can you please also pass the username as well on functions that pass email within the login module? The server I'm authenticating with doesn't use email, so having that passed as well would be a huge help. However that's done doesn't matter (whether it be literally "$email, $username, $password" or "$member, $password"), just as long as I can grab the username.

Thanks :D

[Mat Barrie]

Yeah, the member object is probably the most useful to hand around in those places.

[I am Freddy G]

We've updated changePass to send the plain text password in 3.1 :)

Wait so in 3.1 you can just grab a members password in plain text? I smell danger. :blink:

[Luke]

Wait so in 3.1 you can just grab a members password in plain text? I smell danger. :blink:

...

No. We are talking about login modules. The password is passed in plain text by the user over the loing form, hashed and compared by the internal login module (any and ever web app does this). A custom login module allows you to authenticate an account to another database. This only happens within PHP's internal memory, and is never passed over a network. The problem we are discussing is that the password is not actually passed to the login module and is hashed first. This is a problem because not all login systems hash the password first. So this is change internally so I can hash it within my login module that matches up to my external database. There's nothing to worry about.

[Luke]

Josh did u see the member object / username request?

[Josh]

Josh did u see the member object / username request?

Maybe I'm missing what you're referring to, but it looks like we are passing either the username or member array around in those methods.

EDIT: Nevermind, I see what you mean, will make that change :)

[Josh]

The changePass funciton in han_login now looks like:

	/**

	 * Change a user's password

	 *

	 * @access	public

	 * @param	string		Email address

	 * @param	string		New password

	 * @param	string		Plain Text Password

	 * @param	string		Member Array

	 * @return	boolean		Password changed successfully

	 */

  	public function changePass( $email, $new_pass, $plain_pass, $member )

  	{

  		$this->return_code = 'METHOD_NOT_DEFINED';


		foreach( $this->modules as $k => $obj_reference )

		{

			if( method_exists( $obj_reference, 'changePass' ) )

			{

				$obj_reference->changePass( $email, $new_pass, $plain_pass, $member );

				$this->return_code 		= $obj_reference->return_code;

			}

  		}


  		return ( $this->return_code == 'SUCCESS' ) ? true : false;

  	}

[Luke]

Cool! Thanks Josh! Is the same true with the other functions where email is the first argument, like when the email is changed (when something is updated)?

If you could tell me what the arguments are for the other functions are in 3.1, I'd appreciate it. I'm going to make some direct source modifications to 3.0 for now so that when I update to 3.1 I won't have to make any changes to the login module.

Can't wait until 3.1 :D!!!

[Luke]

Josh can you please look at this:

http://community.invisionpower.com/tracker/issue-21029-loginauth-registration-stuff-missing/

I also added more comments in the first reply (more stuff that I noticed).

Thanks!