Security & User ID'ing

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Security & User ID'ing

Post by McGruff »

I'm trying to work out foolproof ways to identify users.

IP per session: IP can identify a computer but only on a "per-session" basis since users can have dynamically assigned IPs or use different computers. The question I have is this: if there are a bunch of machines on an office network all sharing the same internet access account, would they all appear on the web with the same IP?

Incidentally, the IP per session idea would seem to make cookies unecessary - unless you want to automatically log someone in or have some other need for a permanent cookie. With IP per session, supplying a name and pass would log you in, then the current IP is stored in the database (for each visit) and then checked as necessary. No problems with cookie forging, cookies blocked or deleted, but is it slower to query the database for a "session" IP rather than check for a cookie?

Passwords: assuming you use strong passwords, is md5 unbreakable for all practical purposes, ie can't be bruteforced unless you leave the cracking program running for a few decades? If not, what hash algorithm should I use?

Thanks.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

I am no expert on security, but something about sessions based on IPs: it's a potential problem. Suppose you're on a dial-up, get disconnected and dial back in. Your ISP most likely assigns you a different IP from its IP-pool. You website won't recognise the user - which is not the real problem (re-login).
The problem would be that the original IP with which the session was created is probably assigned to someone else who would have access to this other person's session on your computer.
You'd have to have some safeguards.
Bitmaster
Forum Newbie
Posts: 20
Joined: Thu Nov 21, 2002 8:42 am

Post by Bitmaster »

There are many networks that use NAT (network address translation) to connect to the Internet. A single computer (the gateway) has two IP addresses: One of them is a public IP, connecting to the ISP, the other is a private IP on an interface connected to the network. To the outside world, all computers behind the gateway appear as having just one IP address. So muliple users behind a NAT (or Internet Connection Sharing) gateway won't be able to use your system.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Thanks for the info - I wasn't sure about the NAT thing but now I know.

You're right to point out the problem with a dynamically re-assigned ID. My plan was to store the current IP in a table at each login, use this for authorisation checks, and delete it at logout. However, I can't think of a way to auto-delete it if the user forgets to logout, and without that it's no use - quite apart from the NAT problem.

I need to be able to log users in as well as a system of ban control for abusive forum posters. Here's my current thinking in case it's of any use to anyone. Comments appreciated.

------------------------------------------------------------
Strong cookies

Cookies could be created with randomly variable names and would contain the hashed pass. The current cookie name is then stored in the database and used in auth checks. This makes it impossible to spoof cookies (I think) since the hacker never knows what the name will be - even if he can read your source code. This adds a mysql query to the auth checks, in addition to the cookie var check for a valid pass.

Cookies would be deleted at logout and would also be time-limited to reduce hotseating risks in the event of user forgetting to logout (at the login, always warn them to logout again properly!).

You could also improve things by storing login IP in a table, and in the cookie. Auth checks would look at the pass & login IP given in the cookie then check these against the database records (..at the same time as checking the name of the cookie). That would block a hacker who had sniffed a current, valid cookie - but not hotseating during the life of the cookie (unless the user logged off the net and has a dynamic IP: the hotseater would fail the IP check).

Note that, if a hacker sniffs a cookie with a randomly variable name, he can get the encrypted pass then try to crack it offline. Although he can't spoof a randomly named cookie, with the real pass he can log on anytime to get a valid one.

IP Records

IP records could be useful for ban control.

Supose we create a text column and _suffix ONLY new IPs to it (substr_count($IP, $text) > 0). Later, we can easily explode("_", $text) to get a list of all the IPs the user has ever logged in from.

The size of the stored data shouldn't get too big even with dynamically assigned IPs. We could possibly amend the substr_count() check to look at only the first 5 or 6 characters of the IP: I think they stay the same for dynamic IPs.

Ban Control

We can require user name, pass and email to register and ban on these - but can get around that by registering with new name, pass and email.

We can try to identify a user who has re-registered by storing permanent cookies. The cookie is always set at login, if it doesn't already exist, and thus gets placed on all machines used by the individual. If he re-registers from any computer from which he has previously accessed the site, we can ID him if we find a ban-control cookie.

We should include in the "access denied statement" a note explaining that an individual has made abusive posts from their computer, and include a contact email or address etc. The owner of the machine might not be the troll and should have an option to get himself unbanned.

This would be a second "ban-control" cookie in addition to the (time-limited) login cookie. It could simply be deleted of course - unless he's too dumb to think of that.

We can try banning on IP address but that won't work if he has a dynamic address. We just might get lucky though, and he only has access to computers with fixed IP's (we can find these later from the login IP records). Dynamic addresses may have a common initial sequence: on its own that's not conclusive but, combined with other checks, might help to identify a troll.

Conclusion: We cannot keep a determined troll out of the sysytem. No method is certain to work, so we just have to try them all in the hope that it will be too much trouble to keep re-registering.
Post Reply