6

I've created a login system using PHP sessions.

Here's how it works:

1.) when the user logs in (with the valid login info): Their info (username and password) are stored into a session, along with a few other bits of info: The Expire time: This is just 5mins added onto the current time (so if the user login is at 22:30 the expire time would be 22:35).

2.) On every page view of the user being logged in: The session is checked to see if exists. If it doesn't, the user is redirected to the login page. If the session does exist, it then checks the expire time and compares it with the current time. If the expire time is more then the current time (the user has been inactive for 5+ mins) then their user details (in the session) are checked (compared to ones in database) and the Expiretime session is updated, but if the expire time is less then the current time, It wont check any details, updates the expire time session and will allow the user to carry on. Ive done that to prevent constant querying on the DB to save bandwidth.

So basically, once the user has successfully logged on, their username and password wont be checked on the DB again until they either become inactive (stay on one page) for 5+ mins or if they log out.

FORGOT to mention something guys: The expire time session is actually called expire_time_unique_characters ($_SESSION['expire_time_'.$unique_nu]) which means the evil person will also have to find the $unique_nu when faking the session...

I just have this feeling that its not very secure.

Also, the project this is for is open source (people can see the source code) so that poses an even higher risk here...

can you guys give me some feedback?

Thanks

  • Why store the user/password combination on the server in cleartext? How is _that_ supposed to improve security? If the user/password was wrong, than the session wouldn't have been established in the first place, right? – Niklas B. Dec 17 '11 at 13:33
  • @Niklas The session will only be created once a successful login has been completed. –  Dec 17 '11 at 13:38
  • Then you don't need to recheck the login combination every few minutes. Just don't store the username/password on the server. Plus, don't store them in the database either! Use a strong hashing algorithm for this (preferrably with key stretching) – Niklas B. Dec 17 '11 at 13:40
  • @Niklas I think the creator of this question means that if the user that was logged into the database was erased, he would have been logged out as consequence of not being in the database. – Matej Dec 17 '11 at 13:41
  • @mkram0: He never mentioned something like that. Plus, this could be implemented much easier by destroying active sessions of a user when his/her account destroyed. – Niklas B. Dec 17 '11 at 13:42
  • But whats the chance of someone actually being able to guess the session id? –  Dec 17 '11 at 13:43
  • @Nav: Depends on the entropy of the session ID. PHP provides sensible defaults here, so you can simply use `session_start`. And again, _don't ever, ever, ever_ store plain text passwords in the DB. – Niklas B. Dec 17 '11 at 13:44
  • If your database is on localhost, it shouldn't be depleting your bandwidth so it should be perfectly fine to check the user's session against database every time they reload the page.. – Matej Dec 17 '11 at 13:47
  • @mikram I'm not on local host and that would still slow down the site. –  Dec 17 '11 at 13:55
  • "evil person will also have to find the $unique_nu when faking the session.." That doesn't make sense. Once they have the session id from the cookie, they have the session. Where exactly are you storing this $unique_nu? If it's only server side, the user would never have to spoof it anyway. If it's being sent as a cookie, then it can be grabbed just like the session id. – Corbin Dec 17 '11 at 13:57
  • @Corbin, When i said faking the session, i meant creating a session thats not supposed to be there. –  Dec 17 '11 at 13:58
  • The $unique_nu comes from a separate file in the app but is stored into the session as part of the expire_time session. –  Dec 17 '11 at 14:00
  • If the user can create sessions with arbitrary data, you have major security issues. They would have to trick your scripts into creating a session with a user_id and whatnot. Seems like overkill to put a random string on the timeout. – Corbin Dec 17 '11 at 14:02
  • See http://stackoverflow.com/questions/8318944/did-i-use-session-variable-safely/8324014#8324014 – Cheekysoft Dec 19 '11 at 13:29

2 Answers2

2

Storing user's ID in session is more than enough.

Still, you should implement some kind of protection against session fixation/hijacking.

Mārtiņš Briedis
  • 17,396
  • 5
  • 54
  • 76
0

$_SESSION is relatively secure, provided it's used right. For instance, if you keep the session files below the web root, they cannot be accessed except by someone with direct access to the server filesystem itself. For this reason, you still want to keep the password encrypted, but the username in plain text is perfectly fine.

Keep the session ID in a cookie rather than using the query string method, otherwise anyone copying the URL will inadvertently share their session and bypass login.

That should about do it. Obviously if someone is hacking the user's network and obtains the cookie data then they can use it to pretend to be the user, but there's almost nothing you can do about that. You can make it harder (require the User Agent string to be the same, for instance), but ultimately there's not much you can do if the user's network is compromised. It's not your responsibility to protect their network anyway, only their data on your server.

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • Worth noting that https would remedy the cookie situation (though it's out of the scope of the question, and https would still have issues). – Corbin Dec 17 '11 at 13:50
  • I forgot to also mention something in the question. Can you check my edit out please? –  Dec 17 '11 at 13:57
  • Makes no difference. Access to `$_SESSION` is goverened by the `PHPSESSID` (default name) cookie given by the browser. – Niet the Dark Absol Dec 17 '11 at 16:40
  • So could you explain how someone could actually get into this? Thanks –  Dec 19 '11 at 14:06
  • If someone gets the username and password required to log in to your server via SSH (or FTP if your FTP root contains the session location), then they can access the files directly there and read them. – Niet the Dark Absol Dec 19 '11 at 19:12