Page 1 of 1

Noobish password protection v.2

Posted: Sun May 13, 2007 12:43 pm
by trobale
After some tutorial reading and discussion with other php developers my password protection is as follows:

The users log in on a specific login page, where user name and password are compared to the values in the database. I have passwords encrypted in the database with sha1().

The login.php registers also the ip-address of the user into a mysql table if the user enters wrong user name or password. Then, if the user has tried to log in 3 times in 5 minutes without succeeding, he has to wait another 5 minutes before the next attempt.

If the user name and password check query returns 1 row, the script does the following:

1. Starts a session
2. Fetches the mysql row with username, password and some other information
3. Assigns the users User_ID (taken from mysql table) as $_SESSION['User_ID']
4. Assigns the users IP-address as $_SERVER['REMOTE_ADDR']
5. Sets a cookie with the md5 hash of the ip address joined with a secret word. Eg. md5($_SERVER['REMOTE_ADDR']."secret_word")
6. Gives a header with the location to restricted area.

Then, on every password protected page, I do the following check:

Code: Select all

if(!isset($_SESSION['User_ID']) || md5($_SESSION['IP']."secret_word")!=$_COOKIE['IP']){

          // GIVE A HEADER TO THE LOGIN PAGE
} else {

         // DISPLAY SECRET PAGE
}

What I need from the script:

- A reasonable secure protection.
- Different content for different users. Therefore I need their User_ID registered.
- As little as possible of mysql connections and queries (my host is so slow).

When I first introduced my noobish password protection I got answers that said that it does nothing. I am quite sure that it did a lot, but I found also many things it didn't do and therefore this is my v.2 noobish password protection.

If someone now tells me that the SESSION['User_ID'] and the IP COOKIE check doesn't do anything, I have hard to believe that.

I still have my IP check there because of session steeling. AOL users shouldn't have any problems with that since their ip i stored in a cookie (and then it doesn't matter if their ip address changes)

I hope that you understand how my protection works and I like to have comments on it's security!

Posted: Sun May 13, 2007 1:03 pm
by John Cartwright
Relying on the users IP address for anything is a big no-no. Infact, it is often legitamate that a users ip will change several times, if not every request, during their visit on your website. Only users with a static IP will be able to login.

Posted: Sun May 13, 2007 1:37 pm
by trobale
Thats wrong. The IP address is stored both as a cookie and to the session. They are stored at the same time. It doesn't matter if the IP address changes after that!

The only thing I want to do with the IP thing is to make sure that stealed session id:s are not functional.
I check that it is the same computer that started the session that is continuing the session.

When I look at my code now afterwards, I could have put any other value than the Ip address there... For example some word (hashed of course) or anything like that..

Posted: Sun May 13, 2007 2:54 pm
by Weirdan
I check that it is the same computer that started the session that is continuing the session.
As sessions stealing usually occurs using cookie theft your secret cookie would be stolen as well.

Posted: Sun May 13, 2007 3:58 pm
by JeFFb68CAM
This is not very secure, at all. Stealing the session cookie and your IP cookie = auto login.

Rather redundant too it seems, no more secure than the standard cookie methods.

Posted: Sun May 13, 2007 4:02 pm
by John Cartwright
Yea I mistook $_SESSION['IP'] for $_SERVER['REMOTE_ADDR'], for whatever reason is beyond me.

Posted: Mon May 14, 2007 2:04 am
by trobale
As sessions stealing usually occurs using cookie theft your secret cookie would be stolen as well.
If that is true it's a real problem. As far as I know cookies are stored on the clients computer so you are meaning that hackers hack the clients computer and steal the cookies by that way? Or do they listen to the traffic?

My knowledge of session steeling was that the hacker some way scan for valid sessions id:s on the server through shell access etc.

Does it do any better to save a third value similar to the ip value both in the session and as $_GET in the url. Can url:s also be stolen? If not, it should work.

Posted: Mon May 14, 2007 4:41 pm
by Weirdan
Can url:s also be stolen?
google for xss. And yes, data in the URL is even less secure than cookie (because it's stored in the proxy and webserver logs).
As far as I know cookies are stored on the clients computer so you are meaning that hackers hack the clients computer and steal the cookies by that way?
Actually they hack your site and force it to send javascript code of their choice.

Posted: Tue May 15, 2007 2:49 am
by Maugrim_The_Reaper
My knowledge of session steeling was that the hacker some way scan for valid sessions id:s on the server through shell access etc.
Shell access to the server (esp. shared servers where the session directory is readable), cookie stealing using a Javascript based XSS, network sniffing (just read the transmission between client and server), physical access to the user's PC while they visit the bathroom ;). Any number of methods of stealing session ids. The trick is in minimising the possible damage. For example, you fail to regenerate the session id upon a successful login (counts as an escalation in user authorisation).

Posted: Tue May 15, 2007 6:10 am
by trobale
For example, you fail to regenerate the session id upon a successful login (counts as an escalation in user authorisation)
I don't fully understand this. You mean that you don't allow login if user is already logged in? I have already a check for this. Although it is useless since it relies on the session and cookie.

Since sessions and cookies seems unreliable, what else can I use? And I don't want the user to enter username and password on every page...

Posted: Tue May 15, 2007 7:48 am
by Maugrim_The_Reaper
I think you've been scared a little too much ;). Or maybe just enough to know a lot of care is needed.

Both sessions and cookies aren't perfect, but they are the tools we have to work with and in most cases are just fine. You just need to be aware that there are risks attached. If you don't have one, buy a PHP Security book. It's a life-saver investment.

Take Sessions. The easiest way to steal a session is to steal the session id from the User's cookie. Now consider all the ways of doing that. Which seem most likely? XSS is likely the common one - but you need to visit an infected resource first. Network logging/reading is a lot harder, but if that's taking place then you're already losing (a unique user key like your system or one based on a client fingerprint key helps somewhat). Grabbing it from the shared host's tmp directory is another risk - if that's even possible get a new host and complain...loudly. A better system with less risk is storing sessions to a database.

I guess the message is that there is no perfectly secure system by default. You simply live with the risks, and reduce them as much as possible using best practices. The only near certain security in a HTTP request comes if SSL or similar is being employed (full encryption of the network traffic). On the server side it's in having a dependable host, with flexible user permissions and where (with luck) PHP processes are running under your own account and not the infamous "nobody" typical of many shared hosts.

Posted: Tue May 15, 2007 11:01 pm
by JeFFb68CAM
Maugrim_The_Reaper wrote:I think you've been scared a little too much ;). Or maybe just enough to know a lot of care is needed.

Both sessions and cookies aren't perfect, but they are the tools we have to work with and in most cases are just fine. You just need to be aware that there are risks attached. If you don't have one, buy a PHP Security book. It's a life-saver investment.

Take Sessions. The easiest way to steal a session is to steal the session id from the User's cookie. Now consider all the ways of doing that. Which seem most likely? XSS is likely the common one - but you need to visit an infected resource first. Network logging/reading is a lot harder, but if that's taking place then you're already losing (a unique user key like your system or one based on a client fingerprint key helps somewhat). Grabbing it from the shared host's tmp directory is another risk - if that's even possible get a new host and complain...loudly. A better system with less risk is storing sessions to a database.

I guess the message is that there is no perfectly secure system by default. You simply live with the risks, and reduce them as much as possible using best practices. The only near certain security in a HTTP request comes if SSL or similar is being employed (full encryption of the network traffic). On the server side it's in having a dependable host, with flexible user permissions and where (with luck) PHP processes are running under your own account and not the infamous "nobody" typical of many shared hosts.
Although storing sessions in a database is more secure than in /tmp, I find storing them in memory (mm handler) is always the safest ;)

The only downside is not all servers use this method.