PHP Login Script

Beansprout · 5 Mar 2006 at 01:32

The page ID method is great for SEO, too, if you used wording in URLs and a bit of mod_rewrite trickery.

MoFish · 5 Mar 2006 at 16:08

got that working fine thanks guys.

got another question, but its anoying me. I currently have an index.php using includes to call other pages into the main section of my table. Now I have a core file which contains session start and am using that on a registration.php and a login.php and it doesnt like it. Should i be calling this core once on the index page, and removing it from the login and registration page? or should the session be started when i successfully login, and be removed from the registration and index.php

Ahh hope that makes sence to someone. hehe

thanks mofish

Dj_Jestar · 5 Mar 2006 at 16:27

Sessions should be the first thing that starts, Period.

No matter if the user is logged in, is not logged in, etc. if you are going to be using sessions they should be started before _any_ other action takes place.

MoFish · 6 Mar 2006 at 00:49

I recently tryed to add my login and registration scripts previously made into my design. I added my core on my index page, however my registration and login system have went to pot. They worked perfectly stand alone without being called through an include, but i cant seem to establish what im doing wrong.

MY SITE LINK HERE

This is my first attempt at a website using php, css, and html together so please be nice and say woohoo nice job mofish and stuff, coz then i'll be like all happy and stuff

currently im including the core in my index.php on the 1st line before all html and have removed all includes from the login.php and registration.php as I have already used it in index, which i thought would have established the connection already.

can anyone help me identify where i have went wrong?

Thanks Again MoFish!

include.core.php

Code:

<?php
session_start();
$document_root = dirname(__FILE__);
$document_root = dirname($document_root);
$includes_dir = $document_root.'/includes/';
require $includes_dir.'include.config.php';
require $includes_dir.'include.mysql.php';
?>

include.mysql

Code:

<?php
if (!$dbc = mysql_connect($conf_mysql_hostnm, $conf_mysql_usernm, $conf_mysql_passwd)) {
	$error = 'MySQL Error, '.mysql_error();
	die($error);
}

if (!mysql_select_db($conf_mysql_dbname)) {
	$error = 'MySQL Error, '.mysql_error();
	die($error);
}
?>

config.php
simply includes my database connection details.

Inquisitor · 6 Mar 2006 at 00:56

Just a quick note:
I'd advise against the use of the MD5 algorithm, as it is no longer secure. The source code for quickly calculating MD5 collisions is freely available on the web now.

Instead, use sha1(). Or if you want to be really sure, you could use HMAC-SHA1

Beansprout · 6 Mar 2006 at 01:00

Inquisitor said:
Just a quick note:
I'd advise against the use of the MD5 algorithm, as it is no longer secure. The source code for quickly calculating MD5 collisions is freely available on the web now.

Instead, use sha1(). Or if you want to be really sure, you could use HMAC-SHA1

Salt the MD5 then

md5(rand().'string');

Or something like that at least, I think. It's a longggggggg time since I looked into that sorta stuff

Inquisitor · 6 Mar 2006 at 01:04

Well, you might as well use SHA1 over MD5 anyway, it's not as if MD5 offers any significant advantages

Personally, I use HMAC-SHA1 on my site, with a key defined as constant in a .htaccess protected directory, with lots of security checks everywhere. Am I paranoid? Probably

MoFish · 6 Mar 2006 at 01:52

OK thanks i'll change that for the sha1, as its reccomended.

Back to the the initial problem.. Am I calling my core (session start) at the right time? this should be the 1st line of my index.php and not the registration.php correct?

My login and registation script dont seem to work now that its been put into the design, it doesnt even add the information to the database anymore :eek:

thanks again fella's - Mofish

Dj_Jestar · 6 Mar 2006 at 02:17

Providing you know what you are doing, or can find the script that does it for you, you can find a collision for SHA1 quicker than MD5.

But to put things into perspective, finding a collision for either will take hours, if not days to find. So you won't have to worry about someone gaining access at the click of their fingers, it will require some work, time and patience.

There are a variety of hashing algorithms available with hash() from PHP 5.1.2.

However, a salt is all that is needed, providing you use it wisely.

HTTP requests have one fatal flaw, they are all in plaintext.

So.. to help avoid password sniffing (from packet sniffing,) we can implement a hashing algorithm that takes place on the client, and the server, and is also linked to session_id's to reduce the chances of someone sniffing and stealing the hash'd password + salt and using that to gain access.

All seems a bit complicated and long winded, and it can be at first, but it is currently the safest way to login other than SSL.

MoFish · 7 Mar 2006 at 17:02

>AHH, FALSE ALARM,PROBLEM FIXED!<

ahh, im still having problems getting this registration thing incorperated into my layout. Its not adding anymore and its displaying my echo's and stuff on a new page instead of staying in my main table section! arg!

Should I be using echo's to display the form? would that keep it in my main table section? could it be anything to do with using POST or GET, will that effect things?

This script was ... before i included it! DOH!

can't see what im doing wrong

Inquisitor · 7 Mar 2006 at 17:10

Dj_Jestar said:
Providing you know what you are doing, or can find the script that does it for you, you can find a collision for SHA1 quicker than MD5.

But to put things into perspective, finding a collision for either will take hours, if not days to find. So you won't have to worry about someone gaining access at the click of their fingers, it will require some work, time and patience.

There are a variety of hashing algorithms available with hash() from PHP 5.1.2.

However, a salt is all that is needed, providing you use it wisely.

HTTP requests have one fatal flaw, they are all in plaintext.

So.. to help avoid password sniffing (from packet sniffing,) we can implement a hashing algorithm that takes place on the client, and the server, and is also linked to session_id's to reduce the chances of someone sniffing and stealing the hash'd password + salt and using that to gain access.

All seems a bit complicated and long winded, and it can be at first, but it is currently the safest way to login other than SSL.

Ah my bad...
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
http://theory.csail.mit.edu/~yiqun/shanote.pdf

I was under the impression that SHA1 hadn't been broken yet... seems I was wrong

Dj_Jestar · 7 Mar 2006 at 17:28

Even though they are 'broken' they are still secure.

Why?

Well it comes down to the definition of 'broken'. To 'break' a hash-algo, you must find a method to locate a collision in a faster time than you can by brute force.

So?

9999999999/10000000000 these 'breaking codes' are only just quicker. Some may seem quite a lot quicker, when published as "can find a collision 5 hours faster than brute force" such as the SHA1 'breaking code', but still take a long time to complete. Not checked up the figures, but from memory the SHA1 hash requires something in the region of 10^80 possible combinations to brute it, the breaking method still requires 10^64.. which is still a big number, and will still take a darn long time to find a collision.

Now, if we put in a 10min login timeout, use a salted hash password instead of plain text, and link it to a session ID (which in itself is a 256bit hash number iirc,) the chances of an attacker finding a collision in time is incalculable for my confused brain, but you've probably got more chance of winning the lottery 3times in a row, whilst being struck by lighting 4 times simultaneously at each win, and then catching a meteorite under the nail of your bigtoe and discovering an ancient Yoga tecnique cures death, within the hour.

robmiller · 7 Mar 2006 at 17:50

You're both missing the fact that the most effective way to attack a hash is using rainbow tables, not through finding collisions. Can you imagine what the chances of finding a collision are, nevermind the chances of finding a collision that just happens to hash to a person's password? That's ignoring the fact that you have to get the hash in the first place. No, rainbow tables are the way to go. For thos who don't know, they're basically giant lists of plaintext values and their hashed results, to which you basically do:

Code:

SELECT plaintext FROM rainbowtable WHERE hash = hash_to_crack

And, presuming the hashed value is common enough to be included in your tables, you get the password in a matter of miliseconds, as opposed to hours/days.

As computing power increases, the amount of time it takes to generate rainbow tables decreases drastically, which means that any unsalted hash is technically unsafe.

Obviously salting your hashes avoids this, but not many people seem to.

Dj_Jestar · 7 Mar 2006 at 18:32

Correct, I'm used to preaching this to corporate bodies who are forced to use 'strong' passwords that, in theory, are not common.

Inquisitor · 7 Mar 2006 at 18:39

Indeed rob, which is why my site uses salted hashes, rather than just plain old md5/sha1. Oh and by the way, it only takes 30-45 mins on a desktop computer to find an MD5 collision these days