Re: php vs. apache login verification security?

From: Fred H (secret_at_nospam.com)
Date: 02/26/04 

Date: Thu, 26 Feb 2004 08:39:57 GMT

> I am doing it now by including a function call in each and every page
> which
> calls the php start session function and then after that checks to see if
> the user is logged in. If not, the user is redirected to the log in page.

You could consider to put all pages into one, with a common "top", that
does
all auth stuff, and other common things (?), and then a "require" part that
loads the page the user wants to see. You then of course have to have a
variable
calles "show" or something similar, to select which page you wish to
display.
This would make it easier to maintain the auth and other global routines
you
wish to deploy.

> I know that session info is stored by php in a file on the server, and I
> don't think much of it is stored in cookies. I think PHP just puts info
> into the cookie to allow for session identification. I am thinking here
> of
> your warning of what not to store in a cookie. Can you add anything here
> that I should watch out for or check?

Hm, I don't know. The hashing of username and password is -only- to prevent
cookie snatching. Network sniffing would still get the it all. So you could
consider to use some kind of secure channel between the user and the host,
using "https://". Your webserver need to support this though.

Also, if security is vital to your solution, you should investigate if
there
are schemes that can be deployed to fool your auth system. But don't put
more
into it that it's worth. So the first question you need to answer is,
exactly
what can happen if a "malicious hacker" gets passed your auth scheme.

And here are some random thoughts and ideas for you project:

- Configuration for different timeouts based on:
-- 1: IP-ranges. Longer timeout for your company's IPs.
-- 2: A "I'm at a public PC" setting, like Hotmail had/has. Shorter
timeout.
- You probably got this allready, but: "Log off" functionality.
- Make sure your page "wash" incoming variables! It's a good idea to not
   only wash them, but also store them into some data structure, and unset
   the global vars like $HTTP_POST_VARS and so on...
- Complete blocking based on IP-ranges you *know* your users wont connect
from.

Here are some other random thoughts:

Allways request confirmations for actions that may be harmfull or that
changes
any settings. This is to prevent highjacking of sessions by spoofing a
logged
in users IP-address. This can be for example be done if you don't use
cookied,
and the session id is part of the query string. Then anyone can read it
over
the user shoulder, and may then send spoofed requests to the server. This
also
suggests that you -should- use cookies, in addition to session ids. But a
good
idea would be to store something along the lines of a md5 sum of the
concatenation
of the username and the session id as the username, and likewise for the
pwd.
This is to prevent a "session cookie" to be reused later.

The more I think about it, the more you need a secure connection. Because
unless
you have, there's allways the chance that someone sniffs the users
username and
password. And since you mentioned internet cafes as a possible place to
log in
from, there isn't much you can do to prevent someone from sniffing. Not
all public
LANs are switched all the way to the end computer...

You could of course start using javascript, and fancy auth protocols, and
javascript
encryption. But that's just asking for trouble. Using "https://" is much
easier.

Good luck.

Fred, Norway. 

-- 
Fred H
void FredH::Contact() {
TextToSpeach.say("frode at age dee dee dot en oh");
}

Relevant Pages

  • Re: php vs. apache login verification security?
    ... over the stuff you mentioned, like pwd lifetime, session timeouts etc. ... Use a cookie that holds the username and pwd. ... Use a session db that keeps track of logins. ... Check if a cookie is set with a valid username and password. ...
    (alt.php)
  • Problems with Forms Auth and Session State.
    ... Clearly Forms Authentication manages it's Authorization state using a ... different cookie than the Session cookie. ... using Forms auth to auth the user and set the Auth cookie. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Sessions vs Cookies
    ... There is a session cookie which simply allows the server to identify the client and retrieve relevant session data for it. ... If cookies can be read or forged, it makes little odds whether you have the master key or all the little keys,. ... Suppose you only send the PHPSESSID: Now you cannot change a thing on the server, even if you have the 'master key'. ...
    (comp.lang.php)
  • Re: session wont timeout
    ... Maybe this is a session cookie issue? ... client browser there is this one: WSS_KeepSessionAuthenticated Expires: At ... If I kill the session cookie using IE Developer Toolbar, ... possible and IIS would throw another challenge. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Is it safe to store user_id in Session?
    ... What I was wondering is how safe it is to store user_id or username or ... session so I do not need to search the database all the time. ... OVERRIDING BASIC SESSION COOKIE AUTHENTICATION ... So what is described in the article only works for bad php scripts. ...
    (comp.lang.php)