I know this sounds so basic but... Im just wondering if this approach is right, Id really like to know if I did something wrong. Its the way users log in:


1. Users login at login.php.

2. It gets submitted to home.php which has validate.php included at the top which checks the database for the user and password match. The sanitation for all the POSTs is there too.

3. The validate.php is on every page from then on and the login/password gets passed through the pages as hidden POSTs. So on every page, it gets checked - the user and password match.

4. If you dont get the password right you just get bounced back to the login.



What was I thinking back then:

1. Im passing the password and the user instead of just posting loginsuccessful = 1, coz users can just modify this right?

2. Im making it check every page too in case the user is already logged in, and I need to kick him/her out of the site for some reason.

3. I didnt use GET, sessions and cookies coz I read they can be hijacked so its not safe. So all I have left was the POST.


Thanks

Cookies and Sessions can only be hacked if you use them incorrectly. (For secure data that is)

__________________
My Site

1. That is correct. However, never store raw passwords in the database or the cookie so that a hacker can not see them. Hash the password via SHA1 or MD5 in both the database and the cookie, that way even if the hacker gets the hash he doesn't know the user's password.

2. Always validate the information with the database on every page which they need to be logged in on.

3. You can edit POST just as easily as GET, but POST is not as visible so use it. Just validate the data you get from POST and you will be fine.

I prefer using database sessions to validate the user. This may be a tad too advanced right now, but every time the user logs in make a randomly generated key, store that key in both the cookie and the database (along with the user's ID), use those to match the login with. That way if a hacker grabs the users cookie (or even gets your database), it is useless after the user logs out.

__________________

@VI Would you suggest binding the random ID to an IP to prevent black-hats from using the session when the user is logged in?

__________________
My Site

I use sessions on my personal site already, with the random key for the cookie but never thought of storing it on the database too. Curious, Ill actually try that. I would most likely consider applying this to my other sites. Thanks.

Thank you both for the ideas.

No, IP is not a good method of validating. IPs can change in a session and there are ways to spoof them. This method is about as secure as it comes, it is very similar to what we are doing for an internal file transfer site for our company (a mortgage banker).

HTTP is a stateless connection meaning there is no possible way to know for absolute certain that you are talking to the same person. The only way you can know is to have very hard to spoof data to validate on both ends, this data can always be stolen or faked. To circumvent this the data should change as often as possible so that a cracker's attempt will prove useless before long.

I personally stick away from server side sessions, they have harder to find insecurities and have been less realiable in regards to consistancy from my experience.

__________________