Noobish password protection v.2

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply

Is this kind of protection secure?

Yes
1
17%
No
5
83%
 
Total votes: 6

trobale
Forum Newbie
Posts: 24
Joined: Mon Apr 23, 2007 11:42 am

Noobish password protection v.2

Post 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!
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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.
trobale
Forum Newbie
Posts: 24
Joined: Mon Apr 23, 2007 11:42 am

Post 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..
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post 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.
JeFFb68CAM
Forum Newbie
Posts: 15
Joined: Tue Apr 03, 2007 11:17 pm

Post 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.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Yea I mistook $_SESSION['IP'] for $_SERVER['REMOTE_ADDR'], for whatever reason is beyond me.
trobale
Forum Newbie
Posts: 24
Joined: Mon Apr 23, 2007 11:42 am

Post 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.
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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).
trobale
Forum Newbie
Posts: 24
Joined: Mon Apr 23, 2007 11:42 am

Post 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...
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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.
JeFFb68CAM
Forum Newbie
Posts: 15
Joined: Tue Apr 03, 2007 11:17 pm

Post 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.
Post Reply