How Do You Write Your Login Hanling Scripts?

[Wardrop]

A lot of people have there own way of doing things like this and most the time they employ the same method over and over again. I'm curious to know how you guys write your login handling scripts. By that I mean, how do you write the script that checks if the entered email/username and password match. Don't go into things too specifically, just give everyone a general idea of how you handle the process and maybe some other things you do like security measures you take. I'll get the ball rolling.

$_POST['login_email'] = the email address the user entered.
$_POST['login_password'] = the password the user entered.

$login_query = mysql_fetch_array(mysql_query("SELECT customer_id, email, password FROM user_accounts WHERE email='".mysql_real_escape_string($_POST['login_email'])."'"));
// If the email address is found in the database, continue.
if ($login_query){
// Check to see if the password matches the customer_id. If it does, perform the required tasks to log them in and keep them logged in.
    if (md5($_POST['login_password']) == $login_query['password']){
    // Set some session variables in here to make them logged in and restore things like shopping carts from their last visit. Also set the cookie if they checked the "remember me" box.
        $_SESSION['HTTP_USER_AGENT'] = $_SERVER['HTTP_USER_AGENT']; // Used to prevent php session id spoofing.
    }
} 

You may notice that I set the a session which contains the users http_user_agent. This greatly helps protect against people stealing others php session id's.

I just noticed before posting this topic that I had actually made my script more secure without even realizing it. Some people perform both the email/username check and the password check within the same query, like so...

$login_query = mysql_fetch_array(mysql_query("SELECT customer_id, email, password FROM user_accounts WHERE email='".mysql_real_escape_string($_POST['login_email'])."' AND password = '".md5(mysql_real_escape_string($_POST['login_password']."'"))); 

Where as in my example (the php script closest to the top) I perform the password check after the query in an if statement. Although reasonably minor, it offers a little extra protection just incase someone happens to alter the query.

I'd love to see how some you php pro's tackle the common task of creating a login handling script.

[Cups]

You could consider a "3 strikes and your out" approach, if they get the correct email address (how hard is that?) only go on and do the second password query 3 times, then disable the account or whatever.

Your approach with the user agent reminds me of a class I use called Sessionara.

[superuser2]

After 3 strikes, ban the IP, not the user. Systems like that are easily abused. Very easily abused. Just guess someones password wrong three times and bang, you've started a DOS attack. Denial of Service is really easy with those.

Session holding the User Agent: certianly helps a lot, but I was packet sniffing someone I could very easily get their User Agent header and modify mine to fake it. Of course, if I was snooping the /tmp files, it would be much more difficult.

[geniegate]

A lot of people have there own way of doing things like this and most the time they employ the same method over and over again. I'm curious to know how you guys write your login handling scripts. By that I mean, how do you write the script that checks if the entered email/username and password match. Don't go into things too specifically, just give everyone a general idea of how you handle the process and maybe some other things you do like security measures you take. I'll get the ball rolling.

$_POST['login_email'] = the email address the user entered.
$_POST['login_password'] = the password the user entered.

$login_query = mysql_fetch_array(mysql_query("SELECT customer_id, email, password FROM user_accounts WHERE email='".mysql_real_escape_string($_POST['login_email'])."' AND password = '".md5(mysql_real_escape_string($_POST['login_password']."'"))); 

Where as in my example (the php script closest to the top) I perform the password check after the query in an if statement. Although reasonably minor, it offers a little extra protection just incase someone happens to alter the query.

I'd love to see how some you php pro's tackle the common task of creating a login handling script.

I like your md5 check, generally I don't bother with that for basic membership stuff, as the connection can usually be spied on anyway. (unless you're using SSL) it also makes it difficult for providing "I forgot my password" functionality. I realize a lot of scripts will just reset the password to implement this, but there is still this issue of integration with other tools that might not like the MD5 encryption.

I have a whole framework dedicated to user management stuff.

http://www.geniegate.com/listings/dolphin/

I find that where user logins are required, often several other things such as addresses, icons, preferences, etc.. also need to be stored. To that end, I use a login object which returns a user object. The user object encapsulates all that stuff for me, making it possible to do things such as:

echo htmlentities($user->getUserName()); 

My system doesn't store MD5 encrypted passwords, if I were protecting serious resources (like on-line banks and so-forth) I would have to code that in (and thus blow away my chances of ever integrating with other packages that won't handle Md5 encryption..)

The main trouble with password stuff is that it isn't centralized. LDAP was supposed to address this, but I seldom see it applied. If you can keep your user login stuff isolated to a single file:

require_once('/path/to/login.php'); 

Have this login.php do ALL your login handling, you stand a much better chance of working with other scripts in the future. If you don't do this, you run into the nightmare problem of five different scripts each of which demand their own passwords, changing your password then becomes a nightmare.

[Cups]

After 3 strikes, ban the IP, not the user. Systems like that are easily abused. Very easily abused. Just guess someones password wrong three times and bang, you've started a DOS attack. Denial of Service is really easy with those.

Good point superuser2, I had somewhat trivialised my example I admit, and you are quite right to point out that weakness.

Upon reflection, I only use that with a 3 tier, PIN, username, password system.

[Cups]

After 3 strikes, ban the IP, not the user. Systems like that are easily abused. Very easily abused. Just guess someones password wrong three times and bang, you've started a DOS attack. Denial of Service is really easy with those.

Good point superuser2, I had somewhat trivialised my example I admit, and you are quite right to point out that weakness.

Upon reflection, I only use that with a 3 tier, PIN, username, password system.

[superuser2]

Thank you. 3 tier - interesting. Do you happen to have any articles/resources on that? I'd like to read about it.

[TheRedDevil]

I'd love to see how some you php pro's tackle the common task of creating a login handling script.

You might consider to log each attemt to login, both failures and successful ones. If you do this you can easily give a user a timeout, or review the log at a later time to see if there has been any hacking attemts.

I would also add a good salt to the password, as it is very simple to brute force a short password if you use md5 (when it becomes long enough it takes a lot of time), also if you do this finding a md5 collision will not help the "hacker".

As others has already mentioned not all of the server variables are safe to rely on as they can be altered. Due to this you should for example use the dns of the user into the security hash (The dns can be faked as well, but it require a lot more work). Finally make it into a hash (md5 for example).

After 3 strikes, ban the IP, not the user. Systems like that are easily abused. Very easily abused. Just guess someones password wrong three times and bang, you've started a DOS attack. Denial of Service is really easy with those.

I beg to differ; A valid user might mistype his/her password three times due to they have forgot it. If you ban their IP how will they manage to login?

In addition, do you honestly believe you will stop my attemt to brute force your webpage by banning my IP? I would be trying passwords through multiple proxies at the same time, and when one is "banned" I would just move on to the next proxy.

The key is to make the system as secure as possible, without destroying the user experience. After all, what would your site be without users?

Personally I set a security hash usally of the dns and user hash (you usally do not want to use the IP as some isps will randomly change it during the session, but the dns stays the same; at least to my experience working with aol etc). If the user mistype the password too many times, give him a timeout on x minutes, during this period your login class should see that he is timedout and not process the request.

Final note, even if it is tempting do not use sleep to delay the login attempt. As you will keep a process open during that delay; making it very easy to bring your server down.

I like your md5 check, generally I don't bother with that for basic membership stuff, as the connection can usually be spied on anyway. (unless you're using SSL) it also makes it difficult for providing "I forgot my password" functionality. I realize a lot of scripts will just reset the password to implement this, but there is still this issue of integration with other tools that might not like the MD5 encryption.

Storing passwords in plain text or poorly encrypted is bad. Sure your site might not be a payment processor, but you should take your users into consideration as well. Anyone who gain access to your database (or file storage) will get access to all the password, and you can make sure that some of your users use the exact same password somewhere else.

Imo passwords should always be stored as a one way hash containing the password and a good salt just incase.

Note: If you dont use ssl, you can use javascript to change the password to md5 on the user side. You need to setup a functionality to handle the password if the user does not have javascript enabled as well.

My system doesn't store MD5 encrypted passwords, if I were protecting serious resources (like on-line banks and so-forth) I would have to code that in (and thus blow away my chances of ever integrating with other packages that won't handle Md5 encryption..)

I am curious, what exactly do mean when you say "blow away my chances of ever integrating with other packages that won't handle Md5 encryption", basically every language supports md5.

[Wardrop]

require_once('/path/to/login.php'); 

Have this login.php do ALL your login handling, you stand a much better chance of working with other scripts in the future. If you don't do this, you run into the nightmare problem of five different scripts each of which demand their own passwords, changing your password then becomes a nightmare.

I'll add that to my "to do" list, but I'll store it as a function in my functions.php file. I've made my logout system into a function so I can log users out directly from any file instead of using the header() function to redirect them to the logout page. A decent hacker would be immune to header redirects during scripts so it's always best to avoid redirects where ever possible (in my opinion). Also makes it easier to manage and change an application when it's all centralized using functions and classes (as you all probably already know )

A little off topic, but would it hurt the system performance too much to store log data in both a text file and a database. The plain text file will be good for if a database crashes or the application dies (reading log information from inside phpmyadmin can't be good) while the database would be good to integrate into the backend of the application so the admins can search and sort the log in a nice user interface.

[superuser2]

I beg to differ; A valid user might mistype his/her password three times due to they have forgot it. If you ban their IP how will they manage to login?

In addition, do you honestly believe you will stop my attemt to brute force your webpage by banning my IP? I would be trying passwords through multiple proxies at the same time, and when one is "banned" I would just move on to the next proxy.

I do not mean "ban" in the sense of "block forever". I mean "lockout for 15 minutes". I also believe that the user should be emailed saying there have been 3 invalid access attempts.

Proxies: in a password with only lowercase letters that is 8 digits long (it's a good idea to require at least 6), there are 200 billion combinations. You'd need ~66 billion proxy servers, and you'd set off a few alarms.

It's also a good idea to take 1 password every 10 seconds or so. Really helps prevent bruteforce.

In an attack with 10,000 passwords guessed every second, it would take 242 days to crack an 8-character password of all lowercase letters.

Of course, I'm talking bruteforce. There's still the dicitionary attack to think of.

[Cups]

superuser2
>Thank you. 3 tier - interesting. Do you happen to have any articles/resources on that? I'd like to read about it.

Sorry, no I don't.

First time they login they are prompted for a PIN/username, get that right, set a cookie, and send to another page where are prompted for a password.

Username, stored in a cookie as a key.

From then on, they enter the PIN with the valid cookie, and enter the correct user name and can login.

Should they forget their PIN (what, 4 numbers?), or delete their cookie (more likely), then they have to login again with PIN/user/password combo over 2 pages.

Now if they enter the wrong PIN 3 times, then they have to start over.

If they enter someone elses PIN, ie a valid number but not theirs then shut their account. (I know their cookie key, see?)

No cookie? Start over.

What they generally get is a simpler set of credentials to remember (PIN/user), it seems popular, its very rare the PIN numbers are lost.

Once in, Sessionara then kicks off a dbase based session where I keep a few important variables, important to them, security level, navigational options and the like.

Sessionara then checks every request for a valid key/browser/IP combination. (if my memory is working ... )

The only thing is, this is something I dreamt up for an intranet site, and later used it on a bespoke cms, there are very few users - so it is easy to maintain.

I was more concerned about, 1) usability, and 2) Social engineering, and yes, I used timeouts to shut down sessions automatically - this has proved unpopular.

[superuser2]

Ah, cool. Makes sense.

I used a system a while back where you have a password, that you use everyday to login. Then you also have a 20-character random string called your "key". You needed to use the key only to change your password, or if there was a security watch on your account (i.e someone tried your password wrong 4 times).

[Evelop]

Hey Guys,

Nice thread...I have been wondering for a while now if the way I handle my security is ok.

This is what i use:

class Security {
	function login($user, $pass) {
		$db = new DBClass;
		$sql = sprintf("SELECT pkiUserID, bPermissionsLevel FROM t_gallery_users WHERE sUsername=%s AND sPassword=%s",
						quote_smart($user),
						quote_smart(md5($pass)));
		$db->query($sql);
		if($db->next_record()) {
			SetSession("userID",$db->f(0));
			SetSession("secLevel",$db->f(1));
			SetSession("secureCheck",md5($pass));
			$db->close();
			return true;
		} else
			return false;
	}

	function securityCheck() {
		if((isset($_SESSION['secureCheck']))&&(isset($_SESSION['userID']))) {
			$db = new DBClass;
			$sql = sprintf("SELECT pkiUserID FROM t_gallery_users WHERE pkiUserID=%o AND sPassword=%s",
							quote_smart($_SESSION['userID']),
							quote_smart($_SESSION['secureCheck']));
			$db->query($sql);
			if($db->next_record()) {
				return true;
			}
		}
		return false;
	}
	
	function logout() {
		// Unset all of the session variables.
		$_SESSION = array();
	
		// If it's desired to kill the session, also delete the session cookie.
		// Note: This will destroy the session, and not just the session data!
		if (isset($_COOKIE[session_name()])) {
		   setcookie(session_name(), '', time()-42000, '/');
		}
	
		// Finally, destroy the session.
		session_destroy();
	}
}

I just use the class to group functions, no other reason...

securityCheck() is called by every page (so that query is run every time).

Any advice/comments would be greatly appreciated.

[superuser2]

Why can't you just use $_SESSION? It's a superglobal array. It exists inside that class's scope.

[Evelop]

Why can't you just use $_SESSION? It's a superglobal array. It exists inside that class's scope.

Thanks for your response, what do you mean exactly? I am referencing $_SESSION array in the class?

[wheeler]

question:

how much does this approach add to the strength of md5?

$key = 'long_encrypted_key';
$pass = $_POST['pass'];

if ($db_pass == md5($key.$pass))
{
// your in
} 

[superuser2]

A lot. If that secure key is, say, 32 characters long, and the password 8, one would have to crack a 40-digit hash. Additionally, a dictionary attack would be useless (on the hash itself, of course, not the login page). Not an easy task.

[jazzslider]

I would also add a good salt to the password, as it is very simple to brute force a short password if you use md5 (when it becomes long enough it takes a lot of time), also if you do this finding a md5 collision will not help the "hacker".

I've been researching this tactic a lot lately to see whether or not it would be beneficial to add it into my database-driven content management system, and I haven't been able to find good answers to the following questions...

First...as I understand it, salts only prevent attacks in which the attacker already knows the password's hashed value, right? I.e., if the attacker has been able to find the hash of an unsalted password, he/she can use a hash dictionary to look up the original password and then log into the site using the regular login interface.

Here's the problem, though...in a secure login/password storage system, there is only one way that an attacker could discover the hashed value of a user's password: by directly breaking into the server-side database. And if the attacker already has access to the database, he/she likely already has the ability to do every horrible thing he/she wanted to do to the site, and that without needing site login credentials.

If I'm right about this (and, since I've only just started researching salts, I could easily be wrong), there really isn't any benefit to salting passwords as long as the user information is stored in the same database as the information those user accounts are intended to protect. (And setting up separate databases wouldn't help much either against an attacker who can figure out how to get into them in the first place.)

Any thoughts? I hope I'm not off-topic, but I've been looking for a good place to ask this question for awhile now.

Thanks!

[geniegate]

This is what i use:

class Security {
	function login($user, $pass) {
		$db = new DBClass;
		$sql = sprintf("SELECT pkiUserID, bPermissionsLevel FROM t_gallery_users WHERE sUsername=%s AND sPassword=%s",
						quote_smart($user),
						quote_smart(md5($pass)));
		$db->query($sql);
		if($db->next_record()) {
			SetSession("userID",$db->f(0));
			SetSession("secLevel",$db->f(1));
			SetSession("secureCheck",md5($pass));
			$db->close();
			return true;
		} else
			return false;
	}

	function securityCheck() {
		if((isset($_SESSION['secureCheck']))&&(isset($_SESSION['userID']))) {
			$db = new DBClass;
			$sql = sprintf("SELECT pkiUserID FROM t_gallery_users WHERE pkiUserID=%o AND sPassword=%s",
							quote_smart($_SESSION['userID']),
							quote_smart($_SESSION['secureCheck']));
			$db->query($sql);
			if($db->next_record()) {
				return true;
			}
		}
		return false;
	}
	
	function logout() {
		// Unset all of the session variables.
		$_SESSION = array();
	
		// If it's desired to kill the session, also delete the session cookie.
		// Note: This will destroy the session, and not just the session data!
		if (isset($_COOKIE[session_name()])) {
		   setcookie(session_name(), '', time()-42000, '/');
		}
	
		// Finally, destroy the session.
		session_destroy();
	}
}

Any advice/comments would be greatly appreciated.

I'd say, looks great! Always, always use that same file for every single
login check, never deviate. You might consider an "object factory" (not a huge deal in PHP though.. PHP is rather.. well.. that kind of thing is overkill and will introduce a slowdown.)

That way, if you need to change something later on, you can isolate the authentication code to your single class. Change it there, everything else is updated automatically. I like it.

[voodoomagic]

my security is pretty simple.

i have a login script which checks for empty variables, variables that dont meet the requirements for user name a passwords (1 character things etc, invalid characters symbols etc) then i get the password hash from the database and compare sha1(enterusr.sha1(enterpwd)) == sha1(storedusr.storedhash), and if they are the same hash then, the user is authenticated and a fingerprint is created, and store into the session variable along with and data values that the user will be continuously using over the course of their login sesssion that way i minimize unneeded database queries etc.

then in each page of the logged in area, i include an auth.php file at the top of each script that checks for an initiated finger print variable, and checks that it matches the one that is presented by the user, if so continue with the page, and if not then destroy the session and relogin.

the fingerprint is provided to the server by the client using a cookie. the difference between this and a session id, is that a session id can be passed using get variables where the fingerprint must be a cookie. so the user must have that finger print and the session id in order to properly use the login area.

it seems to be pretty secure and ive spent quite a bit of time reading articles on session security, and this seemed to be simplest, yet most secure way i could do it.

from what i was understanding a salt protects against an attacker being able to guess a users password, by brute forcing with a word dictionnary, because if the password is something like md5(ilovecats), a dictionnary file would easily guess this, but if the password is md5(ilovecats."RKSJFH#(&Y#RJKHSDG"), then it would be way more difficult to guess it. salts are ways to protect simple passwords from being guessed.

[wheeler]

yes this seems like a logical argument voodoomagic, I guess if someone is stupid enough to make their password "password", you would still want to be concerned about preventing a brute force attack on your login page, where the key is not required.

[voodoomagic]

what do you think about my login method/session security?

[jazzslider]

yes this seems like a logical argument voodoomagic, I guess if someone is stupid enough to make their password "password", you would still want to be concerned about preventing a brute force attack on your login page, where the key is not required.

You're exactly right...the salt doesn't protect against that situation on the login page, because the user doesn't have to actively provide the salt; the system handles that after the user submits the unsalted password.

The main benefit of a salt is that it makes it extremely difficult for an attacker to "reverse engineer" the password if they somehow find out its hash. And it actually is quite useful for that...long, random-ish passwords using large character sets are typically out of the practical range of hash dictionary attacks (or so I've read).

The thing that confuses me about all this, however, is that hashed passwords are typically only stored in the server-side database...and if an attacker can access that database (where presumably all the rest of the site's content and data are also stored), then they don't need to bother "reverse engineering" the password, since they've got what they want already (i.e., the ability to do Horrible Things to your site and/or steal your users' private information).

Given this fact, what's the real benefit of salting a password if you're already doing a good job of keeping your database secure (which is a different issue entirely)?

[cranial-bore]

Re: Salting and Hashing passwords
If someone were to determine other users passwords there's a reasonable chance the password could be used elsewhere. A lot of users probably use the same password for their ebay, internet banking, etc. accounts too. Doing a search for their username will probably turn up other sites where they've used it again.

Also storing a hash can help protect the site owner from being able to see passwords. I'd prefer not to see users passwords in plain text when managing a DB.
Imagine for example you're looking at your DB in PhpMyAdmin without SSL.
The usernames and passwords are all being sent to your browser via HTTP which could be intercepted.

Companies that collect such info may not want any employee with DB read access to see user passwords either!

[TheRedDevil]

jazzslider:

The thing that confuses me about all this, however, is that hashed passwords are typically only stored in the server-side database...and if an attacker can access that database (where presumably all the rest of the site's content and data are also stored), then they don't need to bother "reverse engineering" the password, since they've got what they want already (i.e., the ability to do Horrible Things to your site and/or steal your users' private information).

Given this fact, what's the real benefit of salting a password if you're already doing a good job of keeping your database secure (which is a different issue entirely)?

As others have mentioned, the reason you use salt is not to make the initial login process more secure. But to increase the security incase someone get access to the hash which contain the password, making it harder to re-engineer.

For example, if company A do not hash the password, and company B hash the passwords with a added salt. Lets imagine that both companies get their servers hacked and the user table is stolen.
While the fact that the server got hacked is bad publisity in its own, company A would get slaughtered in the press due to the passwords was not secured properly.

In addition, even if a "hacker" get access to the user table it is not sure they have access to any vital parts of the webpage. If you create a properly secured webpage, you will use different database users for different tasks. So even if you get ahold of one of the database users, you will only be able to reach a small part of the database.

Of course if the server itself is breached, none of your security mesures will help as the hacker got access to edit the files directly.
Many people forget this, and do not patch/update the webservers regulary...
As always, "A chain is never stronger than the weakest link."