Massassi Forums Logo

This is the static archive of the Massassi Forums. The forums are closed indefinitely. Thanks for all the memories!

You can also download Super Old Archived Message Boards from when Massassi first started.

"View" counts are as of the day the forums were archived, and will no longer increase.

ForumsDiscussion Forum → [tech] PHP / MYSQL question
12
[tech] PHP / MYSQL question
2007-08-26, 5:46 PM #1
I'm a member of the Society for Technical Communication, and I volunteered to build a PHP-driven site for my chapter for free because I feel that the opportunity will help me become a better PHP programmer.

I've been doing fine so far, but I've hit a problem on the php login script that I plan to implement in various ways throughout the project. Basically, when I try to log in with a member profile that I KNOW FOR SURE is in the MYSQL database I set up, the script still can't find the login info in the table and executes the unsuccessful login code instead.

To try this for yourself, go to ocstc.net and try logging in with username "Neo" and password "theone".

The script currently runs without throwing any errors, but it still doesn't work right and I've been fighting with it for a week.

Here's my code:

[php]
<?php include("header.php"); ?>

<?php

// Login Script version 0.0.7

// Get our form data

$user = trim($_POST[username]);
$pass = trim($_POST[password]);

// define our database parameters

$dbhost = 'localhost';
$dbuser = [censored] // My supervisor won't let me give this info out
$dbpass = [censored] // Not this one either

if ($user && $pass) {

// make the connection, or die trying

$con = mysql_connect($dbhost, $dbuser, $dbpass) or die('Error: Could not connect to database');

$dbname = 'ocstcnet_main';
mysql_select_db($dbname);

$result = ("SELECT * FROM members WHERE username='$user' AND password='$pass'");
mysql_query($result);

if ($user == $result['username'] && $pass == $result['password']){
echo "Username is good; further content can be added";
}

else{

$error2 = "<br>";
$error2 .= "<h2>Error</h2>";
$error2 .= "<br>";
$error2 .= "<div class='php_output'>The username <b><i>". $user . "</i></b> and password <b><i>" . $pass . "</i></b> is not in the database.</div>";
$error2 .= "<br>";

echo $error2;
}

}

else {

$error1 = "<br>";
$error1 .= "<h2>Error</h2>";
$error1 .= "<br>";
$error1 .= "<div class='php_output'>You must fill in all fields!</div>";

echo $error1;


}

?>

<?php include("footer.php"); ?>
[/php]
If I can get help, I will credit anyone who can solve this in the source code.
2007-08-26, 6:16 PM #2
Use ASP.net lol

Sorry I can't help. .(
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-08-26, 6:32 PM #3
I don't know where to begin..

1)
$user = trim($_POST[username]);
$pass = trim($_POST[password]);

Should be

$user = trim($_POST['username']);
$pass = trim($_POST['password']);

Although what you have will work, it's bad practice and could cause problems if there were a constant defined called username or password. Turn error reporting to E_ALL & E_NOTICE and this will throw notices.

2)
Your first problem with the login itself is you're not actually doing anything with the data after you've retrieved it from the database.
[php]
$result = ("SELECT * FROM members WHERE username='$user' AND password='$pass'");
mysql_query($result);[/php]

Try:
[php]
$sql = "SELECT * FROM members WHERE username='$user' AND password='$pass'";
$result = mysql_query($sql);
$row = mysql_fetch_assoc($result);[/php]

then use $row['username'] to access the username from the database.

Also, using * is horribly inefficient and can be problematic. I'm not going to go into detail because there are hundreds of articles on the subject.

3)
[php]
if ($user == $result['username'] && $pass == $result['password']){
echo "Username is good; further content can be added";
}[/php]

What is this for? You've just queried the database to do this exact same check. If you don't actually need any more info about the user, just do a mysql_num_rows($result) or select count(*)


4) Security.... or complete lack thereof. You seem to be assuming magic quotes are on (which is not a good idea, since in a lot of setups they are turned off for performance and because they're annoying).

Ideally you should be doing (at least) $sql = ('SELECT * FROM members WHERE username="' . mysql_real_escape_string($user) . '" AND password="' . mysql_real_escape_string($pass));

Secondly, you're storing passwords as plain text. Do I even need to say why this is a bad idea? You should store (at minimum) MD5 or SHA-1 hashes or (a better solution) salted hashes.
TheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWho
SaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTh
eJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSa
ysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJ
k
WhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSays
N
iTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkW
2007-08-26, 6:50 PM #4
Yeah, what JKWhoSaysNi said. There's a bazillion things wrong with that script, including many bad practices and SQL injection opportunities.

For me, I'd actually mysql_real_escape_string() the username right off the start so I don't need to run it every time I use it in the script. (The password doesn't need it if you bother to only use the hashed (or hash+salt) password, which you should).

[php]
//You can also condense this:

$sql = "SELECT * FROM members WHERE username='$user' AND password='$pass'";
$result = mysql_query($sql);
$row = mysql_fetch_assoc($result);

//into this:

$row = mysql_fetch_assoc(mysql_query("SELECT * FROM members WHERE username='$user' AND password='$pass'"));
[/php]

Oh, and you should NOT have your database username and password in this script, especially if it's web accessible.

If PHP or Apache were ever to foul up and stop processing, the code would get output like text and anyone visiting the page could see it. You should have the info in a separate file in a non-web-accessible directory and include() it in.
2007-08-26, 7:01 PM #5
Thanks, guys. I'll work those fixes in and post what happens.

I'm obviously still in the learning phase, and I appreciate the help. (Especially the security stuff, because no one ever taught me about that until now.)
2007-08-26, 7:03 PM #6
Originally posted by TheJkWhoSaysNi:

Secondly, you're storing passwords as plain text. Do I even need to say why this is a bad idea? You should store (at minimum) MD5 or SHA-1 hashes or (a better solution) salted hashes.


Can anyone recommend any good tutorials that can teach me how to set that up?
2007-08-26, 7:07 PM #7
Originally posted by Pagewizard_YKS:
Can anyone recommend any good tutorials that can teach me how to set that up?


$pass = md5($pass);
$pass = sha1($pass);

Pick one.

Or if you want to do a salt, that's a bit more complicated and requires adding another row to your login table for the salt. Basically all the salt is is a random character/number value that is tacked onto the beginning (or end) of the password before being hashed and saved into the database. It makes it much harder to brute force the hash if the database was to ever be dumped.
2007-08-26, 7:12 PM #8
Originally posted by Cool Matty:
$pass = md5($pass);
$pass = sha1($pass);

Pick one.

No, pick SHA-1, because it's always much much better.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-08-26, 7:15 PM #9
Originally posted by Cool Matty:
$pass = sha1($pass);


Just wondering --- Would that go into the login script or the add to database script?

I assume the database entries are to be stored encrypted... is this all I have to do to decrypt them?
2007-08-26, 7:18 PM #10
Originally posted by Emon:
No, pick SHA-1, because it's always much much better.


technically:

$pass = hash("sha512", $pass);

is the best but I don't think he's gotta worry too much about that with the rest of his script right now :p
2007-08-26, 7:31 PM #11
The script works now!

Here's what I ended up with:

Code:
<?php include("header.php"); ?>

<?php 

// Login Script version 0.0.8
// By Will Kraft

// Get our form data  

// Help from TheJkWhoSaysNi from forums.massassi.net was provided here to help secure the form postdata
$user = trim($_POST['username']);
$pass = trim($_POST['password']);

//hope the security works.....

//Help provided by Emon and Cool Matty from forums.massassi.net on line 17
//$pass = sha1($pass); 


// define our database parameters 

$dbhost = 'localhost';
$dbuser = [censored]
$dbpass = [censored]
 
if ($user && $pass) {

	// make the connection, or die trying 

	$con = mysql_connect($dbhost, $dbuser, $dbpass) or die('Error: Could not connect to database');

	$dbname = 'ocstcnet_main';
	mysql_select_db($dbname);

	//help with line 28 was provided by TheJkWhoSaysNi and Cool Matty
	$row = mysql_fetch_assoc(mysql_query("SELECT * FROM members WHERE username='$user' AND password='$pass'"));  
	
	if (!$row){
		$error2 = "<br>";
	$error2 .= "<h2>Error</h2>";
	$error2 .= "<br>";
	$error2 .= "<div class='php_output'>The username <b><i>". $user . "</i></b> and password <b><i>" . $pass . "</i></b> is not in the database.</div>";
	$error2 .= "<br>";
	
	echo $error2;
		
	}	
	
	else{
     	 
	echo "Username is good; further content can be added";
	
	}
	
}
		
else {
	
	$error1 = "<br>";
	$error1 .= "<h2>Error</h2>";
	$error1 .= "<br>";
	$error1 .= "<div class='php_output'>You must fill in all fields!</div>";

	echo $error1;

	
	}
	
?>

<?php include("footer.php"); ?>


I tried using
Code:
$pass = sha1($pass); 
but the script returned encrypted output and it wouldn't let me in, so I had to comment out that line to get it to work.


I assume I have to purge the database and then go back and retrofit all of the other scripts I have made to get this to work, right?
2007-08-26, 7:35 PM #12
You still didn't do the mysql_real_escape_string on the username and password which are INCREDIBLY important. Basically, I could wipe your database right now.

Edit: And yes, you'd have to change every script that expects a "plaintext" password to instead use the hashed password.
2007-08-26, 7:42 PM #13
Hashing is not the same as encrypting. Hash algorithms are meant to be one-way. Once something is hashed, you can't get the original value back. You do this with passwords so even if an attacker manages to get the store of passwords, it is useless.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-08-26, 7:53 PM #14
Originally posted by Cool Matty:
You still didn't do the mysql_real_escape_string on the username and password which are INCREDIBLY important. Basically, I could wipe your database right now.

Edit: And yes, you'd have to change every script that expects a "plaintext" password to instead use the hashed password.


Just out of curiosity, how would you go about nuking the database in this situation?

I tried this
Code:
$row = mysql_fetch_assoc(mysql_query("username="' . mysql_real_escape_string($user) . '" AND password="' . mysql_real_escape_string($pass)"); 


and now it's throwing an error:

Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /home/ocstcnet/public_html/member.php on line 36

Did I botch the syntax?

Quote:
If PHP or Apache were ever to foul up and stop processing, the code would get output like text and anyone visiting the page could see it. You should have the info in a separate file in a non-web-accessible directory and include() it in.


Should the include file be stored as a php file, or as something else, and how should I chmod it?


The way my chapter's host is set up, everything is set up to run from the public_html directory in each account's home folder and the only way to get anywhere else is to do it via ssh.


I'm not sure how to navigate dirs like that via a script, could oyu shed some light on that?
2007-08-26, 8:02 PM #15
You did the quotes completely wrong in the query. You put the single quotes outside the double quotes which is what is screwing everything up.

Nuking the database would be as simple as throwing in a carefully crafted SQL statement in the username box of the login page.

The DB info should be in a php file. You can always give an exact filesystem path for include(), like /home/osctcnet/dbinfo.php
2007-08-26, 8:12 PM #16
Originally posted by Cool Matty:
Nuking the database would be as simple as throwing in a carefully crafted SQL statement in the username box of the login page.


Examples are here:
http://en.wikipedia.org/wiki/SQL_injection
2007-08-26, 8:15 PM #17
Originally posted by Cool Matty:
You did the quotes completely wrong in the query. You put the single quotes outside the double quotes which is what is screwing everything up.


I tried that and it still didn't work (I get assorted expected " or ' or T_string errors) What should it look like?
2007-08-26, 8:21 PM #18
Just change it at the top and make it easier on yourself, since you aren't even writing the SQL query right >.>

$user = mysql_real_escape_string(trim($_POST['username']));
$pass = mysql_real_escape_string(trim($_POST['password']));

And good lord, read php.net

They warn you about all of this stuff in the documentation. I'm tired of reiterating the docs for you. Plus, the fact that you're making these massive mistakes on a production site really, really, really scares me.
2007-08-26, 8:57 PM #19
Originally posted by Cool Matty:
the fact that you're making these massive mistakes on a production site really, really, really scares me.


Bull****, man. That's how you learn. **** losing a database. That's the price you pay to learn. It's good that in this case he won't because you gave him good advice, I'm just so ****ing tired of this "OMFG YOU MAY NEVER MAKE A MISTAKE OR YOU'RE A FAILURE FOR LIFE!" BS.
"it is time to get a credit card to complete my financial independance" — Tibby, Aug. 2009
2007-08-26, 9:04 PM #20
Originally posted by Cool Matty:
$pass = md5($pass);
$pass = sha1($pass);

Pick one.

Or if you want to do a salt, that's a bit more complicated and requires adding another row to your login table for the salt. Basically all the salt is is a random character/number value that is tacked onto the beginning (or end) of the password before being hashed and saved into the database. It makes it much harder to brute force the hash if the database was to ever be dumped.


What's wrong with just picking a salt and hard coding it into the script? IE:

$pass = sha("HACKTHISYOUJERKS".$pass);

I'd think it'd be a tad more secure than what you propose since even if the DB is stolen and the hacker has made many accounts with known passwords in there he still doesn't have sample before-hash and after-hash strings.

I'd think brute forcing a hash wouldn't be any harder if you kept the salt stored with it, except that you might not know which end the salt goes on.

I suppose a best solution would be using both techniques, part of the salt hard coded in the script and part of it randomly generated per-password and stored in the DB. :)

2007-08-26, 9:07 PM #21
Originally posted by Freelancer:
Bull****, man. That's how you learn. **** losing a database. That's the price you pay to learn. It's good that in this case he won't because you gave him good advice, I'm just so ****ing tired of this "OMFG YOU MAY NEVER MAKE A MISTAKE OR YOU'RE A FAILURE FOR LIFE!" BS.


Settle down tiger, he's developing the backend to a large production group's website on little to no PHP knowledge. While he needs to have learning experiences and mistakes, he should do it on his own time. He really shouldn't be handling anyone's website with the PHP knowledge he's displayed.

I'd love to humor your crusade against mistake badgers, but Page isn't just making mistakes, he's making core mistakes that you make on your first SQL call test as you're learning PHP, not as you're developing the backend to a production group's website.
ᵗʰᵉᵇˢᵍ๒ᵍᵐᵃᶥᶫ∙ᶜᵒᵐ
ᴸᶥᵛᵉ ᴼᵑ ᴬᵈᵃᵐ
2007-08-26, 9:09 PM #22
Originally posted by Freelancer:
Bull****, man. That's how you learn. **** losing a database. That's the price you pay to learn. It's good that in this case he won't because you gave him good advice, I'm just so ****ing tired of this "OMFG YOU MAY NEVER MAKE A MISTAKE OR YOU'RE A FAILURE FOR LIFE!" BS.


You'd think differently if someone making these mistakes was coding a site on which you stored data you didn't want to lose or get stolen.

Not to mention it would reflect poorly on the Society for Technical Communication if their website was hacked. Not as badly as if they were the Society for Web Security, but you know what I mean.

2007-08-26, 9:09 PM #23
Originally posted by Emon:
Use ASP.net lol

Code:
//In this code we demonstrate an ASP.NET login form that is probably 3x superior.

public void btnLogin_Click(EventArgs ev, object sender)
{
	int iRes = -1;
	try
	{
		//I can store the connect string in a multitude of different things. web.config, XML file, hard-coded
		using (SqlConnection cn = new SqlConnection(_sSqlConnectStr))
		using (SqlCommand cmd = new SqlCommand())
		{
			cmd.Connection = cn;
			cmd.CommandText = "select count(user) from tblUsers with(nolock) where user=@user and pass=@pass";
			cmd.Parameters["@user"] = txtUsername.Text;
			cmd.Parameters["@pass"] = MakeSHA1(txtPassword.Text)
			iRes = (int)cmd.ExecuteScalar();

			//Basically we should get a count > 0 if we our select matches (ie a valid user)
			if (iRes != 0)
				FormsAuthentication.RedirectFromLoginPage(txtUsername.Text,chkSaveState.Checked);
			else
				DoBadUser();
			
		}
	}
	catch (SQLException sex) //Huhuhuhuh
	{
		DoErrorHandling();
	}
}

//The only thing where I might say that PHP has a one up on me, I had to do
//stupid string -> byte[] -> string conversions.
public string MakeSHA1(string sToHash)
{
	if (sToHash == string.Empty)
		return string.Empty;

	byte[] baHashed = new byte[64]; //Is it that big?
	byte[] baStrData = new byte[sToHash.Length];

	baStrData = Encoding.ASCIIEncoding.GetBytes(sToHash);
	
	//This is laziness.
	return (Encoding.ASCIIEncoding.GetString(MakeSHA1(baStrData)));
}

public byte[] MakeSHA1(byte[] baToHash)
{
	SHA1 hash = new SHA1CryptoServiceProvider();
	return hash.ComputeHash(baToHash);
}

Minus the memory failing on me on how functions are defined thus causing me to look up, five minutes.

I'll stop derailing now.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2007-08-26, 9:40 PM #24
I'm learning as I go-- this is one of those "trial-by-fire" projects. When I first started PHP my experience was 100% client-side; I only knew how to do php includes and not much else. Now, I can write simple scripts from scratch.

I'm doing this project only because the chapter is nonprofit and I'm the only one who currently has time to do the actual development to any significant extent.

I'm sure that I'll get there eventually if I stick with it. In that regard, every bit of help is a major asset to me.

I'll stick with PHP because I know virtually nothing about ASP and trying to learn two languages at once is just asking for trouble since it's easy enough to get confused as it is.


Right now, the database has no real data in it (every record is fake for the purpose of testing) so there is no real harm done if someone nukes it now. (besides, I have backup set as a cron job) However, I plan to learn enough to know how to lock it down tight by the time I'm ready to start putting real stuff in there.
2007-08-26, 9:49 PM #25
Originally posted by The Mega-ZZTer:
Not to mention it would reflect poorly on the Society for Technical Communication if their website was hacked.


The Society for Technical Communication doesn't have to worry; I don't control the main STC website (stc.org) and I've never worked on it at all. The only project I have admin access to is ocstc.net, which is limited to my chapter. (for the time being)
2007-08-26, 9:51 PM #26
Could someone post some links to articles with explanations of all this security stuff and how to implement it? I have an old webcomic site project that I can never use because it has absolutely no security and I'd love to get it running one day.
Ban Jin!
Nobody really needs work when you have awesome. - xhuxus
2007-08-26, 10:04 PM #27
Smock, just use a content management system like Joomla.
Bassoon, n. A brazen instrument into which a fool blows out his brains.
2007-08-26, 10:14 PM #28
Originally posted by Freelancer:
Bull****, man. That's how you learn. **** losing a database. That's the price you pay to learn. It's good that in this case he won't because you gave him good advice, I'm just so ****ing tired of this "OMFG YOU MAY NEVER MAKE A MISTAKE OR YOU'RE A FAILURE FOR LIFE!" BS.

I accidently nuked a portion of our database because I forgot to check a section of a SQL script. It was not that significant and we were restored (with fresher data) within the day. These are one of those "oh ****!" mistakes that we all learn and go on.

However, there are some mistakes that just have too high of a cost. If I did "delete * from tblListings --where pkListingId=246789" Whoops! I voided a table that has 1 million+ records and is absolutely vital to the company. Not only is this going to cost you productivity, possibly the whole engineering team a day of productivity.

While learning "trial by fire" is helpful, for many things, you must all ready be familiar with basic practices. In PW's case, every every every programmer who deals with web-based techs/languages (ASP.NET, PHP, Ruby on Rails, etc) should know about basic SQL injection tactics and how to prevent against them before anything is done on live servers. These preventative measures keep "oh ****!" instances to a minimum. SQL injections can be very costly. If a database has very sensitive stuff on it, you damn well better believe it has to be protected against SQL attacks. Sometimes, "mistakes are not an option" just holds true.

I've written poor PHP myself as well. Looking back, I should have NEVER started writing on "production" servers back then.
Code to the left of him, code to the right of him, code in front of him compil'd and thundered. Programm'd at with shot and $SHELL. Boldly he typed and well. Into the jaws of C. Into the mouth of PERL. Debug'd the 0x258.
2007-08-26, 10:47 PM #29
this might be a stupid question, i've not done any sql/asp/php so i'm fairly sure it is. :P if you had the username and password stored as a hash then that would pretty much make it sql injection proof, right?
gbk is 50 probably

MB IS FAT
2007-08-26, 10:50 PM #30
Originally posted by NoESC:
this might be a stupid question, i've not done any sql/asp/php so i'm fairly sure it is. :P if you had the username and password stored as a hash then that would pretty much make it sql injection proof, right?


Kind of the idea.
ᵗʰᵉᵇˢᵍ๒ᵍᵐᵃᶥᶫ∙ᶜᵒᵐ
ᴸᶥᵛᵉ ᴼᵑ ᴬᵈᵃᵐ
2007-08-26, 11:16 PM #31
Originally posted by JediGandalf:
While learning "trial by fire" is helpful, for many things, you must all ready be familiar with basic practices. In PW's case, every every every programmer who deals with web-based techs/languages (ASP.NET, PHP, Ruby on Rails, etc) should know about basic SQL injection tactics and how to prevent against them before anything is done on live servers. These preventative measures keep "oh ****!" instances to a minimum. SQL injections can be very costly. If a database has very sensitive stuff on it, you damn well better believe it has to be protected against SQL attacks. Sometimes, "mistakes are not an option" just holds true.



What you say is true, for sure.

At this moment I'm very glad I made this thread, because it fixed my problem, but more importantly, it brought SQL injection to my attention before anything bad happened. My main priority right now is to harden my scripts and I'll start on that tomorrow.

[Edit] I should probably be running the login script over SSL just for some extra security. Yet another thing to set up!
2007-08-26, 11:19 PM #32
I'll harden your scripts for you. My PHP is sloppy.
ᵗʰᵉᵇˢᵍ๒ᵍᵐᵃᶥᶫ∙ᶜᵒᵐ
ᴸᶥᵛᵉ ᴼᵑ ᴬᵈᵃᵐ
2007-08-27, 12:26 AM #33
Speaking of SQL injections on "production" servers ... the UN site was defaced not long ago with an SQL injection and to my understanding the script that was exploited was blatantly and embarrassingly exploitable and wasn't fixed for a while even after the defacement and reports about it's exploitability
一个大西瓜
2007-08-27, 2:04 AM #34
Did they write nasty resolutions condemning the act and threaten action (with no intention of following through)?
Current Maps | Newest Map
2007-08-27, 5:31 AM #35
Originally posted by The Mega-ZZTer:
What's wrong with just picking a salt and hard coding it into the script? IE:

$pass = sha("HACKTHISYOUJERKS".$pass);

I'd think it'd be a tad more secure than what you propose since even if the DB is stolen and the hacker has made many accounts with known passwords in there he still doesn't have sample before-hash and after-hash strings.

I'd think brute forcing a hash wouldn't be any harder if you kept the salt stored with it, except that you might not know which end the salt goes on.

I suppose a best solution would be using both techniques, part of the salt hard coded in the script and part of it randomly generated per-password and stored in the DB. :)



Read this: http://www.developerfusion.co.uk/show/4679/ has a very nice explanation :)
TheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWho
SaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTh
eJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSa
ysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJ
k
WhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSays
N
iTheJkWhoSaysNiTheJkWhoSaysNiTheJkWhoSaysNiTheJkW
2007-08-27, 6:13 AM #36
In case anyone's wondering, the forums use MD5 sums with a database stored salt.

Also, JediKirby: it's a bad idea to hash usernames. While it would be okay for logging in, oftentimes the username of someone is needed elsewhere (such as saying "Hello, username!"). If the username is hashed, this becomes impossible.
2007-08-27, 7:31 AM #37
It could make for some creatively illegibile usernames, though. :D
Cordially,
Lord Tiberius Grismath
1473 for '1337' posts.
2007-08-27, 1:14 PM #38
I've retroffitted all of my scripts to use SHA1.

New question:

is it possible to display a SHA1-hashed password as plaintext? (for a password recovery script) If so, what code do I need?


also, would using

mysql_real_escape_string($variable);

provide adequate protection?
2007-08-27, 1:32 PM #39
Originally posted by Pagewizard_YKS:
is it possible to display a SHA1-hashed password as plaintext? (for a password recovery script) If so, what code do I need?


The way I understand it, no. The encryption is one-way. You encrypt a password and store it, then, when a user enters his password, the entered password is encrypted the same way as the stored password and compared. You have no access to the actual, plaintext version of the encrypted data.

Instead of using a password-recovery script (for forgotten passwords, I imagine?), you would automatically e-mail users a new password that they could then log in to their account and replace with a new password of their choosing.
Cordially,
Lord Tiberius Grismath
1473 for '1337' posts.
2007-08-27, 1:54 PM #40
You can never get a password back if it has been hashed, which is the whole point of hashing.

mysql_real_escape_string merely escapes all characters that could otherwise be used to break out of the intended part of a database query and allow a hacker free access to the database. It only protects you against SQL Injection, but it's totally essentially because even your Granny could figure out how to do an SQL Injection attack.
Detty. Professional Expert.
Flickr Twitter
12

↑ Up to the top!