1

UPDATE:

RESPONSE FOUND AT:

http://community.invisionpower.com/tracker/issue-21634-md5-once-password-does-not-decode-html-entities/


I want to make a separated page using my forum credentials (I am using Invision Power Board), so I started looking into how to the password works.

Mainly on the members table you have members_pass_hash and members_pass_salt tables and the encryption is done as follow:

/**
 * Generates a compiled passhash.
 * Returns a new MD5 hash of the supplied salt and MD5 hash of the password
 *
 * @param   string      User's salt (5 random chars)
 * @param   string      User's MD5 hash of their password
 * @return  string      MD5 hash of compiled salted password
 */
static public function generateCompiledPasshash( $salt, $md5_once_password )
{
    return md5( md5( $salt ) . $md5_once_password );
}

After that I start doing my page but no matter what I do the password never matches the one in the database.

Even using MD5(CONCAT(MD5(members_pass_salt),MD5('mypass')) direct on the mysql doesn't give me the correct value...

I have also searched on communities and at ipb's forum but can't narrow what could be the problem here.

My code piece that produces the password is as follow:

$password = $this->input->post('password');
$md5_once_password = md5($password);
$password_hash = md5( md5( $salt ) . $md5_once_password );

$salt comes from the database and I have echo it to my page to make sure it was the correct salt as well.

Continuing at IPB code there is also:

if ( $member['members_pass_hash'] == self::generateCompiledPasshash( $member['members_pass_salt'], $md5_once_password ) )
{
    return true;
}
else
{
    return false;
}

And going back to the initial piece of code I posted from IPB it means the password is matched against the field members_pass_hash from the members table with md5( md5( $salt ) . $md5_once_password )

Any ideas of what I could be doing wrong to get the password to mismatch ?

Encoding somewhere or anything ?

UPDATE with hashs for testing:

This one works fine:

salt: Do.|O
password: fsk23478cf
hash: f3f3c75110ea9a27a1c01e580676997f

This one does not work, dont know why yet:

salt: ppxps
password: fsk23478cf!*
hash saved by the forum: d060c2fb78c5b8a9e9d303c7b4fab456
hash created by my aap: 0df0c7f24f7f79bd7ad8e501f5447986

UPDATE2:

Nailed down the problem being the exclamation mark on the password but still don't know what is causing it and how to solve.

Passwords with ! will not match properly and right now I am trying to find out if the forum does anything special to the ! which I haven't found, all I have found is that it does trimming to the password field and then md5 it as said above.

Prix
  • 19,417
  • 15
  • 73
  • 132
  • This is a bit unclear. Are you saying that you're computing a hash with two different bits of code, and the results don't match? – Oliver Charlesworth Nov 09 '11 at 12:17
  • @Oli Charlesworth for some reason yes, and that is what I am trying to find out. Code like it is all the same but the hash never matches for the same password and the saved salt from the db. – Prix Nov 09 '11 at 12:21
  • Ok. Could you post a minimal, self-contained, code example that demonstrates the problem? – Oliver Charlesworth Nov 09 '11 at 12:22
  • Oli Charlesworth seems like I nailed it down to some related in using `!*` in the passwords, now I need to figure out where in the code that is not working out right. Since I changed the password to `fsk23478cf` it worked fine but when I changed it to `fsk23478cf!*` the unmatched hash showed up again. – Prix Nov 09 '11 at 12:45
  • have update my question with hashs and their results when failing with !* if you have any idea :) – Prix Nov 09 '11 at 12:56
  • What exactly does `$this->input->post('password')` do? I'm guessing it pulls in the 'password' field from a form _but_ does it do anything else to it like `rawurldecode()`, `htmlentities()`, `addslashes()` or anything like that that _might_ change the values of "!" or "*"? – CD001 Nov 09 '11 at 13:45
  • @CD001 I don't think so, no, like I said in another comment here `$this->input->post('password')` is from code igniter all recall is that it does trimming by default. – Prix Nov 09 '11 at 13:50

3 Answers3

1

You should be aware that if you give any value to md5(), it will output always the same value.

That being said and assuming you check the same password using both algorithms, it seems like your salt is not identical in these two cases. It may be one char, it may be some invisible char or it may be a different source of the salt, but it seems the salt from first case is not the salt from the second one.

Just make sure you have account on your discussion board and check what password is being checked (maybe save it into a file when the function / method is invoked?) and compare with what you pass to your newly created function.

md5() is not magic and should not behave differently if you pass same values to it - this is the basic foundation of hashing functions. The problem lies within the values you pass to md5().

Tadeck
  • 132,510
  • 28
  • 152
  • 198
  • seems like I nailed it down to some related in using `!*` in the passwords, now I need to figure out where in the code that is not working out right. – Prix Nov 09 '11 at 12:45
  • have update my question with hashs and their results when failing with !* if you have any idea :) – Prix Nov 09 '11 at 12:56
  • @Prix: It seems like an issue with IPB - see [this bug report about problems with login if password has exclamation marks](http://joomlacode.org/gf/project/jfusion/tracker/?action=TrackerItemEdit&tracker_item_id=9856). It would be good to find out how IPB changes password before passing it to `md5()`, so you can mimic this behaviour. Is the exclamation mark deleted or replaced? – Tadeck Nov 09 '11 at 17:22
  • @Prix: Now, when you know it is definitely value passed into the function, try searching IPB code for occurences of "`generateCompiledPasshash`" string and check how the second paramater to this function is being generated. It may pass some processing that does something to the exclamation mark / marks (or even other characters as well, if they are in the password). Tell me what you have found. – Tadeck Nov 09 '11 at 17:26
  • think I found something, but not the function it self, it changes `!` into `!` – Prix Nov 09 '11 at 17:47
  • Tadeck thanks a lot that quote helped me find the answer I have updated my question at the top with the answer. – Prix Nov 09 '11 at 17:59
  • @Prix: Ok. Now find out where is this change taking place - if other chars are changed also, you need to know which chars, so you can reproduce this behaviour in your code. The good point may be searching by function name. – Tadeck Nov 09 '11 at 18:01
  • Tadeck yep the link I post a staff from IPB says they use htmlentities so I have update my question with the solution and links ;) – Prix Nov 09 '11 at 18:03
0

The long and the short on this:

When prepping the plain text IPB password for md5 hashing, run it through htmlentities() first.

Jafo
  • 1,200
  • 2
  • 11
  • 22
  • 1
    actually that was not the case, also this is a pretty old question, but I can recall trying `html_entity_decode` but on top of that IPB also have a password parsing function called `cleanPassword` that can be seen on their api code which was where I found my answer and got the code working, however I dont have the code anymore so that is as much as I recall from it. – Prix Aug 04 '12 at 06:54
0

try to trim your pass, bcs when u have a \n or any other sort of LF at the end the hash will be calculated out of the string + lf. I hope this was helpful.

Falk S.
  • 142
  • 1
  • 1
  • 11
  • code igniter does it by default but I also tried trimming the password and no changes. – Prix Nov 09 '11 at 12:20
  • u can try the other way maybe ipb is doing a LF at the end, so u have to add it? its just a dumb idea – Falk S. Nov 09 '11 at 12:23