Password is not hashed

Worker Joined: Aug 02, 2004 Posts: 165

Why the user password is not hashed in the database (nuke_users)? This affect the users who are registered to the ravennuke after the v2.30 upgrade.

How to fix this?

registered · Posted: Fri Nov 14, 2008 8:40 am

Good question - I think this may be an oversight with RN Your_Account.

Posted: Fri Nov 14, 2008 8:42 am

evaders99 wrote:

Good question - I think this may be an oversight with RN Your_Account.

How should we proceed to get passwords to be hashed with MD5?

Posted: Fri Nov 14, 2008 7:49 pm

mmm well, need a script to determine whether you're using a hash in that field ... 32-chars, and replace with the appropriate hash. Not terribly difficult

Posted: Fri Nov 14, 2008 10:33 pm

I am running a clean install on my test site and all my passwords are hashed.

Can they login? I wouldn't think they could even login if there passwords are not set correctly.

Involved Joined: Apr 06, 2008 Posts: 484

crypto is correct it seems hashing has been forgotten on the user registration side (/modules.php?name=Your_Account&op=new_user)

creating users via the admin area is hashing fine.

I cant believe this got through beta testing with out being noticed.

Posted: Sat Nov 15, 2008 1:22 am

I am assuming this is the issue?

DO NOT change this unless and admin verifies it.

File: modules/Your_Account/public/new_finish.php

Find:

Code:




$user_password = htmlspecialchars(stripslashes($user_password)); // from RN

Change To:

Code:




$user_password = md5(htmlspecialchars(stripslashes($user_password))); // from RN

Posted: Sat Nov 15, 2008 3:05 am

That sounds like a good fix but I have send a note to the Team as I am about to leave for most of the day.

registered · Posted: Sat Nov 15, 2008 7:07 am

Yeah, can't believe we didn't see this either. Unfortunately, since I upgraded to 2.3 on several sites, I am seeing some that are hashed and others that are not and I do NOT add users manually. So, we may have issues in a couple of places.

Posted: Sat Nov 15, 2008 7:36 am

I would suggest a slightly different approach given that $user_password is used later on in the code to present their password back to them (such as in the activation email - although I have never liked that inclusion). Instead, I would add a line underneath for this:

$hashed_pass = md5($user_password);

Then change the INSERT statements to use $hashed_pass instead of $user_password.

Now to figure out how some are getting hashed and the others not... It looks like login attempt might do it, which concerns me.

Posted: Sat Nov 15, 2008 3:54 pm

Thanks, I think that I'll wait until you have checked this out closely. I don't want to mess up anything...

Could you then please publish detailed step-by-step patching/fixing instructions how to get passwords to be hashed.

Posted: Sat Nov 15, 2008 6:44 pm

montego wrote:

Yeah, can't believe we didn't see this either. Unfortunately, since I upgraded to 2.3 on several sites, I am seeing some that are hashed and others that are not and I do NOT add users manually. So, we may have issues in a couple of places.

montego, I adding 2 users via the normal method registering and I added and they where both not hashed, I added one via the admin side and it was hashed.The strange part was later on I checked the db and saw that 2 where now hashed and one was still not hashed?

Posted: Sun Nov 16, 2008 2:42 am

testy1 I am curious about something.
If you look those three users up in the RNYA user search facility; are the ones that were not originally hashed but are now showing a 'last logged in' dte?
Is the one that remains un-hashed showing a last logged in date?

Posted: Sun Nov 16, 2008 8:54 am

BTW, Raven is planning on releasing a patch release pretty soon and it has the fix as well as a script I wrote that you can run to fix the user passwords. Not sure exactly when, but its coming...

Right now, it seems to all still work fine. But, we're still looking into the code to be sure.

Posted: Sun Nov 16, 2008 3:40 pm

Gaurdian I will test this again shortly to make sure

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

When the cat's away, the kittens will play...

Sorry for missing all this fun! I looked at the code changes, and it looks correct, though I haven't verified that login functions correctly (unless it checks both hashed and not).

montego, if unhashed password is > 32, can't the user / admin simply change the password?

Posted: Sun Nov 16, 2008 10:35 pm

Gaurdian,

I ended up testing it further and discovered that if you;

Note: I disabled email activation for ease of registering

Create a new account URL:account-new_user.html
At the end of the registration RN informs you that you have been logged in successfully (which you are).I then checked the database and the password was not hashed (although I could access the forums alright).

I then logged out and logged back in and checked the database and the password was now hashed

RN has a new security feature that automatically re-hash's your password when you log back in Smile

Posted: Mon Nov 17, 2008 12:10 am

testy1 wrote:

RN has a new security feature that automatically re-hash's your password when you log back in Smile

Why would it do that?

Posted: Mon Nov 17, 2008 1:02 am

for example if someone were to hack into your database and un-hash your password it would be re-hashed for you Razz

Posted: Mon Nov 17, 2008 7:53 am

Posted: Mon Nov 17, 2008 12:11 pm

testy1 wrote:

I then logged out and logged back in and checked the database and the password was now hashed

Hmmm, it seems that all of those new (registered) users which IP has been saved to the "last-ip" column, have now hashed passwords.

Weird part is that all of those users have "last visit time", but only half of them IP's have saved to the db.

Posted: Tue Nov 18, 2008 3:24 am

testy1 - thanks for that!
I noticed in my own DB that the last 4 users to register had not got hashed passwords and it wasn't until I remembered I had had more than 4 people register since using RNYA and the only pattern I could see is that the unhashed users had never actually logged in. As I have admin approval turned on I need to check that isn't interfering.

Posted: Tue Nov 18, 2008 7:16 am

Yes, keep in mind that with the new RNYA, once you activate your account, it sets the login cookie. So, essentially, you are "logged in" and it never hits the login code. This is why the password is not hashed yet even though you are able to do things as if you were logged in (because you are!).

I also don't know why that re-hash code is there. In fact, if you open up the script, you will see my comments to that effect right there next to that "re-hash" code. However, at the time of trying to get 2.3.0 out the door, it was better to just leave it there. I am now wondering if that bit of code was really a "bubble-gum-in-the-dike" kind of thing from the authors long back. Don't know. RNYA came from CNBYA...

I still don't like how it was not hashed and I made the code changes already to RN in our subversion repository as well as provided a conversion script. The code that testy1 posted is good, but it will mess up the email notice, so I tweaked it a bit.

I still haven't had to time to review the security aspects of this and probably won't in a few days. So, if another RN developer can spare the time, it would be a good exercise to go through IMO...