PHP and MySQL PASSWORD() Problem

[ScrollMaster]

Hello PHP Freaks,

I am working on building my User Authentication System unforently I am having Trouble.

I created a Register Function that takes care of signing up the user.

[code]
        function register($username, $password, $email)
        {
            $username = dbC::clean($username);
            $password = dbC::clean($password);
            $email = dbC::clean($email);
            $bUsername = false;
            $bEmail = false;
            $hp = "Breath deep in the SaltMines OmenKing, So you can feel the sting that you placed on others";
            #Check User Name-------------------------------------------------------------------
            $check = dbC::query("SELECT usr_ID FROM sm_User WHERE usr_Name='$username'");
            if(mysql_num_rows($check) == 0 )
                $bUsername = true;
            else
                echo 'Sorry the User Name '. $username . ' has Already Taken' . '<br />';
            #Check Email Address---------------------------------------------------------------
            $check = dbC::query("SELECT usr_ID FROM sm_User WHERE usr_Email='$email'");
            if(mysql_num_rows($check) == 0 )
                $bEmail = true;
            else
                echo 'Sorry the Email Address ' . $email . ' has Already been Used' . '<br />';            
            #Register the New User-------------------------------------------------------------
            if( $bUsername && $bEmail )
                dbC::query("INSERT INTO sm_User (usr_Name, usr_Password, usr_Register, usr_Email) VALUES( '$username' , PASSWORD('$password') , NOW(), '$email' )");    
        }
[/code]

The Register Function Works with No Problems.

The Problem I am having with is loggin in.
Here is my Login Function
[code]
        function login($username, $password, $remember)
        {
            $username = dbC::clean($username);
            $password = dbC::clean($password);
            $check = dbC::query("SELECT usr_ID FROM sm_User WHERE usr_Name='$username' AND usr_Password=PASSWORD('$password') ");    
            echo mysql_num_rows($check);
            if(mysql_num_rows($check) == 1 )
            {
                $_SESSION['LoggedIn'] = true;
                echo 'Logged In';
            }
            else
                echo 'Sorry the User Name '. $username . ' with the Given Password Does not Match' . '<br />';            
        }    
[/code]

When I attempt to Login it does not Work.
I am for some reason having a hardtime matching up the the Password.

If I stip away the PASSWORD() mysql function then it works correctly.
Is there something I don't know about PASSWORD() mysql function?

[fenway]

Seems strange, but why are you using MySQL's internal PASSWORD() function?

[ScrollMaster]

Well Im pretty much new to this and the examples I have seen uses the PASSWORD function. Though I know there is another function that can salt it or I guess I could use md5 and then pass the function into the database.

I just thought it be easier if I used one of mysql encpytion functions.

Could you sujest a better method?

[fenway]

[!--quoteo(post=387755:date=Jun 25 2006, 10:05 AM:name=ScrollMaster)--][div class=\'quotetop\']QUOTE(ScrollMaster @ Jun 25 2006, 10:05 AM) [snapback]387755[/snapback][/div][div class=\'quotemain\'][!--quotec--]
Well Im pretty much new to this and the examples I have seen uses the PASSWORD function. Though I know there is another function that can salt it or I guess I could use md5 and then pass the function into the database.

I just thought it be easier if I used one of mysql encpytion functions.

Could you sujest a better method?
[/quote]
MD5 is reasonable, depending on what you're trying to secure; obviously, AES is usually overkilll, but does the job well too. Be aware, though, that using the MySQL functions (any of them, really) means you're sending the plaintext password in your query over an insecure channel -- you should probably be using the PHP-equivalent and then simply storing the encrypted text instead.

[Wildbug]

[!--quoteo(post=387945:date=Jun 26 2006, 02:46 AM:name=fenway)--][div class=\'quotetop\']QUOTE(fenway @ Jun 26 2006, 02:46 AM) [snapback]387945[/snapback][/div][div class=\'quotemain\'][!--quotec--]
MD5 is reasonable, depending on what you're trying to secure; obviously, AES is usually overkilll, but does the job well too. Be aware, though, that using the MySQL functions (any of them, really) means you're sending the plaintext password in your query over an insecure channel -- you should probably be using the PHP-equivalent and then simply storing the encrypted text instead.
[/quote]

You could also look into a JavaScript implementation so that you won't be transmitting plaintext passwords from client to server. Moving plaintext between PHP and MySQL on the same machine is barely the security risk that public client-server plaintext transmission is.

These are good JavaScript implementations: [a href=\"http://pajhome.org.uk/crypt/\" target=\"_blank\"]http://pajhome.org.uk/crypt/[/a]

[fenway]

[!--quoteo(post=388075:date=Jun 26 2006, 10:44 AM:name=Wildbug)--][div class=\'quotetop\']QUOTE(Wildbug @ Jun 26 2006, 10:44 AM) [snapback]388075[/snapback][/div][div class=\'quotemain\'][!--quotec--]
You could also look into a JavaScript implementation so that you won't be transmitting plaintext passwords from client to server. Moving plaintext between PHP and MySQL on the same machine is barely the security risk that public client-server plaintext transmission is.

These are good JavaScript implementations: [a href=\"http://pajhome.org.uk/crypt/\" target=\"_blank\"]http://pajhome.org.uk/crypt/[/a]
[/quote]
Perhaps, but any plaintext ends up in logs all over the place; morever, you can't possibly rely on client-side code (JS) to do the encryption, because it can be turned off.

[Wildbug]

No, you can't [i]rely[/i] on it, but you can implement it to take advantage of the folks who do leave their JavaScript on (most of them).

My last login/authentication system used client-side JavaScript to SHA1 the username/password before sending it to PHP and MySQL. Of course, I had to check on the server-side to see if they had been encoded because (as fenway points out) the user may not have JavaScript capabilities.

The point is, if you've just dragged a plaintext password halfway around the world through a dozen intermediate points in the first place, you probably don't need to obsess over moving plaintext data between PHP and MySQL on the same machine.

MySQL recommends against using their PASSWORD() function for your own password schemes since it's supposed to be used for MySQL passwords and the underlying algorithm can be changed at any time. There are several other functions available in both MySQL and PHP including MD5 and SHA1.

Then there's also SSL.

[fenway]

[!--quoteo(post=388152:date=Jun 26 2006, 02:19 PM:name=Wildbug)--][div class=\'quotetop\']QUOTE(Wildbug @ Jun 26 2006, 02:19 PM) [snapback]388152[/snapback][/div][div class=\'quotemain\'][!--quotec--]
No, you can't [i]rely[/i] on it, but you can implement it to take advantage of the folks who do leave their JavaScript on (most of them).

My last login/authentication system used client-side JavaScript to SHA1 the username/password before sending it to PHP and MySQL. Of course, I had to check on the server-side to see if they had been encoded because (as fenway points out) the user may not have JavaScript capabilities.

The point is, if you've just dragged a plaintext password halfway around the world through a dozen intermediate points in the first place, you probably don't need to obsess over moving plaintext data between PHP and MySQL on the same machine.

MySQL recommends against using their PASSWORD() function for your own password schemes since it's supposed to be used for MySQL passwords and the underlying algorithm can be changed at any time. There are several other functions available in both MySQL and PHP including MD5 and SHA1.

Then there's also SSL.
[/quote]
Of course... if it's plaintext anywhere during the transmission between client and server, there's no point to just doing it at the last step. Presumably, that won't be the case if you're sending anything that actually is important.