Page 1 of 1
Login Security
Posted: Sat May 13, 2006 1:37 am
by s.dot
Aside from the typical login security questions (challenge/response, hashing/encrypting, and the likes) I'd like to know how secure my method of verifying that the user logged in, is indeed the user who logged in through the form.
I will address the aforementioned topics in later posts.
When a user logs in, I store their session ID in the database.
Then on every page load, I check to make sure that session_id() is equal to this session id stored in the database. If it doesn't match, I log them out.
Is this enough?
Should I create a random key as well to check against along with the session id?
Perhaps when they login, do something like this
Code: Select all
<?php
$rand = rand(20,30);
$hash = substr(sha1(uniqid(1)),0,$rand);
// store it in the database
$_SESSION['key'] = $hash;
?>
and then check against that as well as the session_id() on every page load?
Would this be overkill, or just an additional layer of security?
It's not like i'm protecting sensitive data like money, but obviously I don't want anyone to be able to get into others accounts.
I understand that a login is only as strong as its weakest link, so I want to make sure this link is solid before addressing other login topics.
Thoughts, opinions, ideas?
Posted: Sat May 13, 2006 4:19 am
by Maugrim_The_Reaper
Any systems weakest link in PHP on shared hosting at least - is session security. So yes, formulating a unique hash for every request will add security - but, ah, putting it in the session is circular thinking. If the Session is already compromised, so is any data it contains. You could (possible overkill) force the user to submit a unique key every request - something appended to all URL links and/or forms. Change it on every request and ensure its useable only once, and two users on the same session becomes...difficult.
Also, storing sessions on the database completely (needs a custom session handler) removes the risk of session files being compromised as it common on shared hosts where session files are written to /tmp or someplace else all users on the same machine have read access.
What you're aiming at, more than securing a login, is securing the integrity of your session. Slightly different focus...
Posted: Sat May 13, 2006 1:25 pm
by s.dot
This is a dedicated server.
Posted: Tue May 16, 2006 5:33 pm
by s.dot
Any other thoughts on this?
Posted: Thu May 18, 2006 5:22 am
by remco-v
You could store the ip addres when they login.
Then check on every request if its still the same.
I think sometimes it can happen than a user might loose his login this way not sure on that one.
But i use it as an extra layer, dont cost much resources.
And seeing its a dedicated host you could go ssl ?
Posted: Thu May 18, 2006 5:29 am
by Benjamin
I assign logins a unique key stored in a session. Using this key I can query the database for the following information. This makes it easy to time out a login and lock it down to an IP.
Member ID
LastActivity (in microseconds)
IP Address
Posted: Thu May 18, 2006 11:39 am
by aerodromoi
agtlewis wrote:I assign logins a unique key stored in a session. Using this key I can query the database for the following information. This makes it easy to time out a login and lock it down to an IP.
Member ID
LastActivity (in microseconds)
IP Address
I wouldn't tie it to an ip address - some users use dynamic ip addresses.
aerodromoi
Posted: Thu May 18, 2006 12:06 pm
by alex.barylski
It doesn't make sense to use IP addresses as a type of user identity check...
Sure it might work %90 of the time...but what about the %10 of time someone spoofs an IP?
If a solution isn't effective 100% of the time...what is the point in using that tehnique?
Here are somethings to consider:
If your on a shared host...storing sesisons in a database is a good idea...however, if your PHP scripts are insecure, SQL injection would make it possible to retrieve that session data. So if you have a lot of third party scripts (ie: phpBB, and so on) and your not sure of their security policies (do they escape characters, etc) perhaps it's a good idea NOT to store your session data in database, but perhaps in a file in your document root and protect that file using
.htaccess I'm willing to bet far fewer scripts have holes allowing direct file access exist than do SQL injection scripts...
This is something only you can determine based on your unique situation...
If session data is only storing things current page, last viewed records, etc...
There is no reason you cannot use generic sessions, as security isn't really an issue...
And
scottayy your comparing the session ID or magic cookie on the client machine to that stored in a database... *is* IMHO a secure way of doing business...
I am sure there are ways of further enhancing security, like regenerating a session ID every request, so any given session ID (stored on client as cookie) can be used only once...but then...why not just use SSL? Solve the problem of sending data over the wire...thr right way...
Regenerating session ID's might work (sorta) but your driving the nail into the board using a screw driver here...
Meaning...yes you might get the job done and the solution works...but christ...what a waste of time...
If you have reason to believe your netwrok traffic is being sniffed...perhaps it's best to look into it deeper than just PHP level security...and if security is that big of a priority...perhaps it's time to upgrade to a server which allows SSL???
If you are worried that someone might obtain a copy of the cookie using some sneaky javascript...thats a problem with your code, so solve the problem where it starts not where security becomes an actual problem...
Cheers

Posted: Thu May 18, 2006 6:26 pm
by s.dot
Indeed. Like I said it's not like I'm protecting sensitive government secrets or monetary data

I just don't want people to be able to login as somone else (makes sense!).
I believe that this is a secure way of validating the user logged in is really the one that logged in through the form, but I think I'm going to generate a hidden value in the form that will be unique every time, and check that on every page load as well.
Thanks for the tips!
Posted: Thu May 18, 2006 6:44 pm
by John Cartwright
Hockey wrote:
Sure it might work %90 of the time...but what about the %10 of time someone spoofs an IP?
I just want to point out that there are legimate reasons for a user's ip to change several times during a session, *cough cough* people on AOL.
Posted: Sat May 20, 2006 2:58 am
by AGISB
Jcart wrote:Hockey wrote:
Sure it might work %90 of the time...but what about the %10 of time someone spoofs an IP?
I just want to point out that there are legimate reasons for a user's ip to change several times during a session, *cough cough* people on AOL.
Is this really still so? I knew it was like this at least till 2002 but I actually never heard of any problems lately.
Posted: Sat May 20, 2006 3:00 am
by AGISB
I like to check a couple of other things like the Http_User_Agent. If the user agent changes a reauthenticate is in order.
Posted: Sat May 20, 2006 4:32 am
by aerodromoi
AGISB wrote:
Is this really still so? I knew it was like this at least till 2002 but I actually never heard of any problems lately.
Yep - that's a positive (at least till 2005

).
aerodromoi
Posted: Sat May 20, 2006 4:47 am
by Benjamin
LOL, Thanks to AOL, yes there are users who do seem to have a different IP on every page request. Thankfully, my login system allows for turning this lockdown function on or off depending on the clients needs.