Jump to content


Photo

Password input being altered incorrectly for loginauth


In reference to this document: http://community.inv...ogin-modules-r7

When a user has a password that contains the any of the following characters:

!*&"<>\'

  • Exclamation
  • Star
  • Ampersand
  • Double quote
  • Less than
  • Greater than
  • Backwards slash
  • Single quote
IPB converts them to HTML codes before they are placed in the $password variable. When using a third party authentication that has passwords with those characters, you may end up feeding the wrong password to the third party authentication. As such, a user may have set a password with one of those characters, but may never be able to authenticate, because the password is being altered in IPB before being passed to the third party authentication system.

So entering

~!@#$%^&*()_+{}|:"<>?`-=[]\;;',./


Getting the password from $password, gets this:

~&#33;@#&#036;%^&amp;*()_+{}|:&quot;&lt;&gt;?`-=[]\;&#39;,./

With an MD5 hash of: 4FDD3C288BC79394A5CDE8357E35D4DF

While getting the password directly from the form submission via $_POST["ips_password"] or $_POST["password"], gets this:

~!@#$%^&*()_+{}|:"<>?`-=[]\;;',./

With an MD5 hash of: 14B954C33ADD5FBB42AAC05C891C7D04

Issue #032018 may be affected by this issue, because other boards pass the raw $_POST string to the MD5 function then store the password.

IPB must not sanitize the $password variable, or provide an alternate variable that has an unsanitized raw password entry.

Status: Fixed
Version:
Fixed In:


5 Comments

Take a look at the LDAP login module.

$password            = html_entity_decode($password, ENT_QUOTES);
        $html_entities        = array( "&#33;", "&#036;", "\" );
        $replacement_char    = array( "!", "$", "\\" );
        $password             = str_replace( $html_entities, $replacement_char, $password );

This can be handled within the custom login module IMO (and has been ever since they were implemented - this isn't something new/changed recently)
(Note that IPB converted & #092; to \ in my post above)
Photo
James Hawkwind
Mar 14 2012 12:21 AM
Then it is requested that the documentation be updated to make note of the necessary re-encoding and desanitization of the password input.
In what version this issue has been fixed?
The software was not altered, the documentation was updated to reflect what happens.

http://community.inv...ogin-modules-r7