updating database

[PHPDevil]

Hi

I'm having some difficulties with a database. I got a forgot password script which I've made. I got to the process where ive md5 and created the new password with rand

now when i run my sql query the database doesn't seem to update the new password

 

if ($email == $dbemail && $lname == $dblname)
            {
            $password = rand(10000,20000);
            $passnew = md5($password);             
            mysql_query("UPDATE users SET userpass='$passnew' WHERE email='$email'") or die(mysql_error());
            $checkpass = mysql_query("SELECT * FROM users WHERE email='$email' AND userpass='$newpass'");
            $nnum = mysql_num_rows($checkpass);
                       if ($nnum == 1){
                             echo "Password was changed succesfully";
                             }                        
                             else {
                             echo "Error occured";
                             }
            }
         else {
            echo "email not sent. details arent te same";
              } 

 

i believe the issue lies there. I keep getting the "error occured" message on the site.

If more of the script is needed please let me know

Thanks!

[Spudinski]

Problem #1: You're using ext/mysql, get rid of it.

I think your problem lies within in initial query, assign the return value to a variable and validate it.

Better yet, use *_affected_rows() to validate that something has indeed been updated - and then remove the SELECT query(seems unneeded?).

[PHPDevil]

lool sorry. I didn't understand what you said :(

im pretty basic to all of this.

[SilverStar]

if ($email == $dbemail && $lname == $dblname)
            {
            $password = rand(10000,20000);
            $passnew = md5($password);            
            mysql_query("UPDATE users SET userpass='$passnew' WHERE email='$email'") or die(mysql_error());
                             echo "Password was changed succesfully";

            }
         else {
            echo "email not sent. details arent te same";
              } 

[Spudinski]

if ($email == $dbemail && $lname == $dblname)
            {
            $password = rand(10000,20000);
            $passnew = md5($password);            
            mysql_query("UPDATE users SET userpass='$passnew' WHERE email='$email'") or die(mysql_error());
                             echo "Password was changed succesfully";

            }
         else {
            echo "email not sent. details arent te same";
              } 

[Djkanna]

lool sorry. I didn't understand what you said :(

im pretty basic to all of this.

if ($email == $dbemail && $lname == $dblname) {

   $password = rand(10000,20000); //Why?
   $passnew = md5($password); //Urm...

   if (mysql_query('UPDATE `users` SET `userpass` = '.$passnew.' WHERE (`email` = '.mysql_real_escape_string($email).')')) {
       if (mysql_affected_rows() == 1) {
           echo '<p>Password updated.</p>';
       } else {
           echo '<p>Password could not be updated.</p>';
       }
   } else {
       trigger_error('Query error: '.mysql_error(), E_USER_ERROR);
   }

}

[AnonymousUser]

lol my thoughts exactly on the $password DJK :p

[HauntedDawg]

DJK, what if somewhere in the system there is 2 user accounts with the same email but not login name? You will have 2 affected row's meaning, you will be displaying to the user their password could not be updated.

So kindly make sure where email is one being submitted and login name is one being submitted.

[Djkanna]

DJK, what if somewhere in the system there is 2 user accounts with the same email but not login name? You will have 2 affected row's meaning, you will be displaying to the user their password could not be updated.

So kindly make sure where email is one being submitted and login name is one being submitted.

First of all, you're making presumptions about the OP's database structure.

Second: An email should be considered somewhat unique, therefore you should not actually run into a duplicate email account.

Thirdly: Where does login name come into play in this?

[HauntedDawg]

Firstly, never assume.

Secondly, MCCode does not use indexing properly, thus the email field is not even considered to be unique.

- And, who's to say the OP/Admin didnt set up a demo account with their same email address?

Login name is clearly the $lname variable.

 

if($dbemail == $email AND $dblname == $lname)	{
# Everything checks out, continue.
$password = mt_rand(10000,20000);
$passnew = md5($password);

try	{
	if(mysql_query('UPDATE `users` SET `userpass` = "'.$passnew.'" WHERE `email` = "'.$email.'" AND `login_name` = "'.$lanme.'"'))	{
		if(mysql_affected_rows())	{
			echo '<p>Password has been successfuly updated.</p>';
		}	else	{
			echo '<p>Some records do not match this account. Please try again.</p>';
		}
	}	else	{
		throw new Exception('MYSQL Error: '.mysql_error());
	}
} catch(Exception $e)	{
	echo '<p>Caught Exception:</p><br />'.$e->getMessage();
}
}

 

NOT TESTED.

 

@DJK: Think of this scenario.

I manage to gain access to an SQL exploit, i hereby change your email address to mine. I request a forgot password to my email address for my account. Everything matches up. Your account password is now my new password, my password is also the new password. Figure out your login name, and im into your account.

But that's a bit to much of a work around to get into the admin's account. But then again, what if you had a demo admin account. You'd realize that i am new to the staff list. But you won't realize i have access to the demo admin account. From there, i can keep on screwing up, while you "assume" the attack is from another place.

Edited September 17, 2012 by HauntedDawg

[Octarine]

... I manage to gain access to an SQL exploit, i hereby change your email address to mine ...

At that stage everything else becomes utterly irrelevant. It doesn't matter of your code does or not handle some odd aspect of your game code or not. The simple fact that somebody has managed to gain access means that all your code, and data must be treated as hostile.

What's wrong with using the primary key in the WHERE clause? Anything else - especially something that can be changed by the players opens you up to race conditions again. Primary keys can be considered immutable in this context, whereas things like login name / username / email address / password etc are all highly liable to change whether under direct user control or not.

Line #1 is performing a test - against the database, therefore, the correct row will have already been read into memory, and thus the primary key is available.

[HauntedDawg]

Octarine, just explaining that specific scenario, obviously if found an SQL Exploit, much more damage than just changing the email address can be done.

I agree to use the primary key, if i see the rest of the script would be easier. However, in this case. The email field is NOT (by my knowledge) a primary key and shouldn't be treated as one.

Primary key (being the users ID) would be the best solution in this case.

[rulerofzu]

I dont see any mention that its MCC

[Djkanna]

Firstly, never assume.

Secondly, MCCode does not use indexing properly, thus the email field is not even considered to be unique.

- And, who's to say the OP/Admin didnt set up a demo account with their same email address?

Login name is clearly the $lname variable.

if($dbemail == $email AND $dblname == $lname)    {
   # Everything checks out, continue.
   $password = mt_rand(10000,20000);
   $passnew = md5($password);

   try    {
       if(mysql_query('UPDATE `users` SET `userpass` = "'.$passnew.'" WHERE `email` = "'.$email.'" AND `login_name` = "'.$lanme.'"'))    {
           if(mysql_affected_rows())    {
               echo '<p>Password has been successfuly updated.</p>';
           }    else    {
               echo '<p>Some records do not match this account. Please try again.</p>';
           }
       }    else    {
           throw new Exception('MYSQL Error: '.mysql_error());
       }
   } catch(Exception $e)    {
       echo '<p>Caught Exception:</p><br />'.$e->getMessage();
   }
}

NOT TESTED.

@DJK: Think of this scenario.

I manage to gain access to an SQL exploit, i hereby change your email address to mine. I request a forgot password to my email address for my account. Everything matches up. Your account password is now my new password, my password is also the new password. Figure out your login name, and im into your account.

But that's a bit to much of a work around to get into the admin's account. But then again, what if you had a demo admin account. You'd realize that i am new to the staff list. But you won't realize i have access to the demo admin account. From there, i can keep on screwing up, while you "assume" the attack is from another place.

You're doing it again.

Making even more presumptions, there is and has been no mention of MCCodes.

Look at the code provided, do you see any mention of a login_name column? No.

Using the primary key, that's absolutely fine, even I agree. Just one thing, do you happen to know what that is in this case?

See, as much as I hate to say it, but I'm not a mind reader, I've no idea if the OP is using MCCodes (though there's a similar db structure from what we've been given, but it means diddly squat).

So you give help with what they've provided, because if you just assume, and your assumption is way off, you're no help to the one having troubles.

Edited September 17, 2012 by Djkanna

[HauntedDawg]

`userpass` gives it all way he is using MCCode's.

I might be "assuming" the he is using mccode's, but your method is incorrect. You don't even think of vulnerabilities. The primary key for the users table is `userid` as i said here:

 

Primary key (being the users ID) would be the best solution in this case.

 

Then again, seems like I'm arguing with a bunch of nitwit's that think the security only lies within certain parameters. (On exception 2 people from this thread).

Or do you mind explaining your preferred method of use for this situation, with in mind that the OP is not using mccode's and we are unsure if the email address is unique or not, ontop of that, the possibility of 2 accounts having the same email address. Please.

[Djkanna]

`userpass` gives it all way he is using MCCode's.

No it doesn't.

I might be "assuming" the he is using mccode's, but your method is incorrect. You don't even think of vulnerabilities. The primary key for the users table is `userid` as i said here:

Do you even read what I say, I help with what I've got, for all I know, there is no primary key for this users table (unlikely, but perfectly plausible), I try to help with what I am given, back to the point of assuming what you don't know, can be very unhelpful. On the same note, how exactly do you know userid is the primary key for this users table? Oh wait assumptions.

Then again, seems like I'm arguing with a bunch of nitwit's[...]

Then stop arguing with yourself.

[HauntedDawg]

Until you can prove he doesn't use MCCode, your argument is invalid. So keep quiet until then.

[Djkanna]

Until you can prove he doesn't use MCCode, your argument is invalid. So keep quiet until then.

Until you can prove he does use MCCodes, your argument is equally invalid, however feel free to continue this drivel you're spewing.

[HauntedDawg]

I can't prove he is using McCodes, but i can guarantee 95% that, that script is meant for MCCodes. What's your guarantee he is not using McCodes?

I am happily fine to continue :)

[Djkanna]

I can't prove he is using McCodes, but i can guarantee 95% that, that script is meant for MCCodes. What's your guarantee he is not using McCodes?

I am happily fine to continue :)

I don't have a guarantee the OP is or isn't using MCCodes, or that what this script is intended to be used with.

Back to the original point, don't assume the OP is or isn't, help with what's provided.

You may continue, however I won't, as it's not helping anyone.

Just amusing a few people. ;)

[lucky3809]

I am off topic, I assume you all hate mccodes lol...

[HauntedDawg]

I don't have a guarantee the OP is or isn't using MCCodes, or that what this script is intended to be used with.

Back to the original point, don't assume the OP is or isn't, help with what's provided.

You may continue, however I won't, as it's not helping anyone.

Just amusing a few people. ;)

Clearly, you might have some issue with me..so.. to the point.. because i pointed out a possible flaw/vulnerability, you take it offensive to say the OP is not using MCCode's and by all means trying to argue that statement? Sheesh.. Thats bad.. When you've worked with mccode's and moved to a complete new standard & methods, you can clearly see when MCCode's is being used or not.

I like to amuse people :), rather be wierd, than be boring :D

[Djkanna]

Clearly, you might have some issue with me..so.. to the point.. because i pointed out a possible flaw/vulnerability, you take it offensive to say the OP is not using MCCode's and by all means trying to argue that statement? Sheesh.. Thats bad.. When you've worked with mccode's and moved to a complete new standard & methods, you can clearly see when MCCode's is being used or not.

I like to amuse people :), rather be wierd, than be boring :D

Ha! - My reply is sent in a PM, I'd advise you to do the same, if you wish to continue this charade.

----additional not in pm----

As for being offended, quite frankly I am.

I'm offended when you use a quote such as: "Sheesh.. Thats bad..When you've worked with mccode's and moved to a complete new standard & methods, you can clearly see when MCCode's is being used or not".

That just means I've wasted my time, for one we're not even talking about MCCodes, we're not even in the MCCodes board.

The funny thing is, I've not once argued that it's not or it is MCCodes, all I have argued is, you're assuming it is, when it's certainly plausible that it is not, in which case everything you've said, is pretty much unhelpful to the OP.

And I'm the one that's hung up on MCCodes. :rolleyes:

I am off topic, I assume you all hate mccodes lol...

On the contrary, I don't have a problem with MCCodes.

Edited September 17, 2012 by Djkanna

[rulerofzu]

LOL get out the wrong side of bed yesterday HD?

So who is working to a complete new standard and methods? you?? Have we swapped who is riding the high horse!

This really is a pointless argument as you can only work with the information placed before you.

Its not the mcc board so may not be mcc regardless of the userpass and other similar terms used. They are not "difficult" column names to think of and are not solely used in mcc.

I could argue in return that the code is using mysql_query rather than $db->query so its not v2 could be v1 or could be neither. Its just silly to bother about it.

Email. The point is invalid as the remainder of the OP's code has not been seen for example checking for email on registration and therefore no duplicates are allowed.

As this topic has already done this can go back and forth on and on and on.

Really just help the OP and leave it there. Move that nag along now.