Fixed Password authentication problem from Imported IPB 3 forums

[TJ Adams]

I did a conversion from IPB 3.4 to XenForo and found that a percentage of members were unable to authenticate on their first login attempt. But, many users could authenticate fine.

Took a while to figure out, but, the information on how passwords are treated in IPB is explained here:

https://www.invisionpower.com/support/guides/_/advanced-and-developers/integration/login-modules-r42

In the middle of that page is this:

The $password, $email_address and $username variables that are passed to this method have already been run through the IP.Board input cleansing routines, meaning certain characters have been replaced with HTML entities. If your external application does not do the same thing, this may mean usernames or passwords with special characters will fail if you do not account for this. The special characters that IP.Board will replace are:

• & to & (do this first so that you don't double convert any others below)
• \ to &#092 ; ( no space between 2 and ; )
• ! to !
• $ to $
• " to "
• < to &lt;
• > to &gt;
• ' to &#39;

You may wish to convert these characters back to their original form in the corresponding variables before sending them to your remote application for validation, if appropriate.

IPB actually runs the plain text password through that cleaning routine before doing the hash operation. I confirmed it by manually generating the hashes with and without cleaning the password first.

The XenForo module that authenticates IPB login credentials does not take this into account. It just does the basic: return md5(md5($salt) . md5($password)); operation.

I made an edit in: ./library/XenForo/Authentication/IPBoard.php - adding a function to do the same character substitutions prior to testing the hash, and that addressed the problem.

When researching this, I was surprised it wasn't found before this. There are a couple threads here about passwords not always working on some IPB imports, but, nothing about this.

 

[Mike]

I've added these conversions as an additional check, since this is the first I've heard about this and I don't want to accidentally break auth (particularly if this didn't apply to older versions).