PHP Login Not working?

[Jessica]

Again, what does it matter if it's encryped? I'm asking seriously.

if you return the encrypted version of the password from the database, what's the point in encrypting it in the first place?

... Did I miss something where one way hashes no longer exist???

 

Look I am all for security but in this example, if you look at the scenario I described above, it's not user friendly to NOT differentiate between a password mismatch and a username not being found. You can't argue that it's user friendly to not tell a user they mistyped their username. If you're concerned about brute force attacks, limit login attempts!!!

 

BTW, I'm pretty sure I DID say seriously. I'm not claiming to be an expert on security. I'm seriously asking, if IN a login script, there is an actual security concern with selecting an encrypted version of a password (like 35d05678b659f08cb7e40ec5fb6f1b38). In your PHP script. The same place you store mysql username and password NOT encrypted.

 

The first person who can tell me what string I typed to get the above hash, I'll personally mail you a $20. I'm dead serious. I'm posting it here on a public forum (no, that's not my real password), and I'm talking about selecting a password from your database into a php script.

[The Little Guy]

Can you show me an example of how you can do this? Where you can tell the difference between a mismatched password and a user not existing, and only do one query?

 

 

select (select count(*) from users where username = 'dog' and password = md5('xxxxxx')) as user_found, (select count(*) from users where username = 'dog') as user_exists;

[Jessica]

Can you show me an example of how you can do this? Where you can tell the difference between a mismatched password and a user not existing, and only do one query?

 

 

select (select count(*) from users where username = 'dog' and password = md5('xxxxxx')) as user_found, (select count(*) from users where username = 'dog') as use_exists;

You realize that's still two queries?

Which is fine, it's really not that big a deal. I was mostly being hypothetical on not doing 2 queries.

[The Little Guy]

Can you show me an example of how you can do this? Where you can tell the difference between a mismatched password and a user not existing, and only do one query?

 

 

select (select count(*) from users where username = 'dog' and password = md5('xxxxxx')) as user_found, (select count(*) from users where username = 'dog') as use_exists;

You realize that's still two queries?

Which is fine, it's really not that big a deal. I was mostly being hypothetical on not doing 2 queries.

 

No, it is one query with two selects.

[Muddy_Funster]

hmm one way hashes have nothing to do with it. Let me try and break this down for you, you seem to be having dificulty here:

signup ->

  hash your password ->

    put it in db ->

      login ->

        pull hashed password out of db during login check (along with every other bit of info as it's a SELECT *) ->

          sql injection captures hashed password for all users ->

            sql injection uses direct comparison with capured hash and stored hash to circumvent the point in hashing the password in the first place ->

              injection attacker has now got full access to any and all accounts.

 

My point is, as long as you never return a password (hashed or not), it's never made available to anyone that doesn't already know it.

 

your turn, explain why you would actualy return the password? What do you gain?

[The Little Guy]

What do you gain?

 

database access!

 

What do I win?

[Jessica]

hmm one way hashes have nothing to do with it. Let me try and break this down for you, you seem to be having dificulty here:

signup ->

  hash your password ->

    put it in db ->

      login ->

        pull hashed password out of db during login check (along with every other bit of info as it's a SELECT *) ->

          sql injection captures hashed password for all users ->

            sql injection uses direct comparison with capured hash and stored hash to circumvent the point in hashing the password in the first place ->

              injection attacker has now got full access to any and all accounts.

 

My point is, as long as you never return a password (hashed or not), it's never made available to anyone that doesn't already know it.

 

your turn, explain why you would actualy return the password? What do you gain?

 

1. I never said do a select *

2. What SQL injection? If your site is open to SQL injection, it doesn't matter what you SELECT, the person doing the injection can select whatever they want. Are you trying to imply that you never do ANY Select statements? (not SELECT *, I get that you think that's the devil's work, but selecting anything) For that matter, if you're open to SQL injection, it doesn't matter if you're selecting, updating, whatever.

 

Since you're so concerned with security, your site should definitely be protected from SQL injection, not relying on security by obscurity.

 

What I gain by selecting the username and password at the same time is the ability to do what I described in my original complaint about this, without doing a second select statement. That is all. I'm not saying anyone has to do it this way, I just don't see what the harm is.

[Jessica]

What do you gain?

 

database access!

 

What do I win?

What are you TALKING about? How on earth is selecting a hashed password different from selecting a username, or id, or last_time_logged_in, and how would any of that give anyone else access to your database? We're talking about a site user's login password, not a database user's password.

[The Little Guy]

Ever heard of a rainbow table?

 

And how do you know that the username/password isn't a login to a database?

[Muddy_Funster]

1. I never said do a select *

2. What SQL injection? If your site is open to SQL injection, it doesn't matter what you SELECT, the person doing the injection can select whatever they want. Are you trying to imply that you never do ANY Select statements? (not SELECT *, I get that you think that's the devil's work, but selecting anything) For that matter, if you're open to SQL injection, it doesn't matter if you're selecting, updating, whatever.

 

Since you're so concerned with security, your site should definitely be protected from SQL injection, not relying on security by obscurity.

 

What I gain by selecting the username and password at the same time is the ability to do what I described in my original complaint about this, without doing a second select statement. That is all. I'm not saying anyone has to do it this way, I just don't see what the harm is.

1 - my first post on this thred (that you quoted) was against the use of select *, I was carying on the theme.

2- It's a simple basic example, please don't concern yourself with the securty of my code.  Of couse I use selects, although when I'm feeling especialy paranoid I run them as stored procedures through an intermediary refference table making it twice removed from the front end.

 

I have already made it clear that there is no need to pull the password out of the database for your initial complaint, it can be checked in place with no loss of end user support.

 

What are you TALKING about? How on earth is selecting a hashed password different from selecting a username, or id, or last_time_logged_in, and how would any of that give anyone else access to your database? We're talking about a site user's login password, not a database user's password.

I suppose we should stop masking password fields and show our passwords next to our names on our profile pages as well?  What makes passwords different, what defines them, IS how we treat them.  They aren't just another bit of information to stick against our name on a social networking site, they aren't supposed to be passed around like just another piece of data. 

database access!

 

What do I win?

PMSL I like it.

[Jessica]

2- It's a simple basic example, please don't concern yourself with the securty of my code.  Of couse I use selects, although when I'm feeling especialy paranoid I run them as stored procedures through an intermediary refference table making it twice removed from the front end.

 

I have already made it clear that there is no need to pull the password out of the database for your initial complaint, it can be checked in place with no loss of end user support.

 

I understand that there is no need to, but you guys are now insisting that by doing so, you are compromising security, and have yet to explain how. Simply saying SQL injection isn't an explanation. You have YET to explain HOW by the php script selecting the hashed password, ANYONE could then get it and look it up in a rainbow table, or do anything else with it. That's my question.

[The Little Guy]

Recently PHP had security issues with people being able to get data that shouldn't have been able to get (I don't remember which version it was). A few weeks after it was released a new version was released to patch the security hole.

 

Now lets say you have a site that grabs that data from a database, php releases a new version and you decide to upgrade your version of php which has a hole that allows people to grab variables on a page which now has all the data you grabbed from the database is now accessible.

[Muddy_Funster]

2- It's a simple basic example, please don't concern yourself with the securty of my code.  Of couse I use selects, although when I'm feeling especialy paranoid I run them as stored procedures through an intermediary refference table making it twice removed from the front end.

 

I have already made it clear that there is no need to pull the password out of the database for your initial complaint, it can be checked in place with no loss of end user support.

 

I understand that there is no need to, but you guys are now insisting that by doing so, you are compromising security, and have yet to explain how. Simply saying SQL injection isn't an explanation. You have YET to explain HOW by the php script selecting the hashed password, ANYONE could then get it and look it up in a rainbow table, or do anything else with it. That's my question.

You are opening up the option.  It's pointless to constantly go on about this, you're clearly either incapable of getting past the concept of "hashing brings kittens back to life", or that you were wrong, and I honestly don't care which.  I said there is no reason to ever do it, now your picking on security problems, so here - packet capture between web server and database server.  Just because no one has an agenda to blow up a country is no excuse to be careless with how you transport your plutonium.  It should never be about finding reasons to not pass security information needlesly about the place.  Youre perspective is all wrong and I'm done trying to get that through to you.

[Jessica]

Yeah, I'm the one here who's incapable of admitting when I'm wrong.

*eyeroll*

People say that *I* am rude. But rather than actually having a discussion, you'd rather be sarcastic and pretend like it's shocking that someone might not just take your word as gospel when you say "don't do X". When people question *MY* comments I can almost always back them up with an example either in actual code or in documents and articles. Rather than saying stupid shit like "hashing brings kittens back to life" you could actually, you know, answer the question and teach someone something. I fully admitted here that I am not an expert and I guess you decided that was liberty to treat me like an imbecile.

 

@The Little Guy - thank you for coming up with an actual example, I appreciate you actually taking my question seriously.

[chriscloyd]

I dont know if this will work but there are two options you can do that works for me

<?php

session_start();

// dBase file

include "../admin/config.php";

$User = mysql_real_escape_string($_POST["username"]);

$Pass = mysql_real_escape_string($_POST['password']);

if ($User == '' || $Pass == '' ?) {

	die("You need to provide a username and password.");

} else {

	// Create query

	$q = "SELECT * FROM `nm_users` WHERE `username`='{$User}' AND `password`=PASSWORD('{$Pass}') LIMIT 1";

	// Run query

	$r = mysql_query($q);

	//you can do it two ways to make sure your even getting anything back

	$num = mysql_num_rows($r);

	if ($num > 0) {

		$obj = mysql_fetch_object($r);

		// Login good, create session variables

	  	$_SESSION["valid_id"] = $obj->id;

	  	$_SESSION["valid_user"] = $obj->username;

	  	$_SESSION["valid_time"] = time();


	  	// Redirect to member page

	 	Header("Location: members.php");

	} elseif ($r) {

		//or you can do this

		$obj = mysql_fetch_object($r);

		// Login good, create session variables

	  	$_SESSION["valid_id"] = $obj->id;

	  	$_SESSION["valid_user"] = $obj->username;

	  	$_SESSION["valid_time"] = time();


	  	// Redirect to member page

	 	Header("Location: members.php");

	} else {

	  	// Login not successful

	  	die("Sorry, could not log you in. Wrong login information.");

	}

}

 [/Code]

[Muddy_Funster]

Yeah, I'm the one here who's incapable of admitting when I'm wrong.

Correct, for once.

 

People say that *I* am rude.

Well that makes sense - you are.

 

But rather than actually having a discussion, you'd rather be sarcastic and pretend like it's shocking that someone might not just take your word as gospel when you say "don't do X".

Others and myself atempted the discussion rout at the start of the thred, it became aparent very quickly it was pointless with you.  I don't care if no one listens when I make suggestions, it's not my script they are writing. I do however get frustrated by stupid little girls making lame excuses just because they do it too.

 

When people question *MY* comments I can almost always back them up with an example either in actual code or in documents and articles.

Just like the twice now I have asked you to back up your side of the argument?  Where's the code or article that justifies passing password information in any form to and from a database, at every login atempt, when it is expressly unnescasery, as a good coding practice? I'd LOVE to read that.

 

Rather than saying stupid shit like "hashing brings kittens back to life" you could actually, you know, answer the question and teach someone something.

Like I already did? Seems as though if anyone learns something, it's never going to be you.

 

I fully admitted here that I am not an expert and I guess you decided that was liberty to treat me like an imbecile.

Nope, that was all you're shouting down from your high horse that did that one.

[xylex]

I'm with Vel on not allowing people to fish for valid usernames, but to answer Jesi's question on how to do the password comparison in one query without pulling the has from the DB, assuming that "secret" is the hashed password column -

 

SELECT username, CASE secret WHEN '$hash' THEN 1 ELSE 0 END as password_matched FROM users where username = '$username';