Oh no another question on login scripts. Sorry but I just wanted to
check if the way I propose to do it would be acceptable...

User's details are stored in a database.

User logs in with username and password.

Database is checked for match, if ok then store a random string to a
session and the database against that user.

If they checked the "remember me" box then the string is also stored
to a cookie.

Then on every page that requires you to be logged in, it first checks
that the session exists, if it does then look for it in the database,
if not, it checks that a cookie exists, if not go back to login. If
cookie exists, then store the cookie value to the session string.

Then try to find the session string in the database, if it does then
thats that user and you can get details.

Sound about right??

Cheers

Mike

On May 3, 1:01 pm, Mike <m... [at] mjfcadsolutions.co.uk> wrote:
> Oh no another question on login scripts. Sorry but I just wanted to
> check if the way I propose to do it would be acceptable...
>
> User's details are stored in a database.
>
> User logs in with username and password.
>
> Database is checked for match, if ok then store a random string to a
> session and the database against that user.
>
> If they checked the "remember me" box then the string is also stored
> to a cookie.
>
> Then on every page that requires you to be logged in, it first checks
> that the session exists, if it does then look for it in the database,
> if not, it checks that a cookie exists, if not go back to login. If
> cookie exists, then store the cookie value to the session string.
>
> Then try to find the session string in the database, if it does then
> thats that user and you can get details.
>
> Sound about right??
>
> Cheers
>
> Mike


you might like to consider adding to this the requirement that on
"admin" pages, or "user detail" pages, the user has to re-enter their
password, this amounts to forcing a quick input for certain pages and
checking the hashed value is the same as the user obtained from the
session string. You might want to expire the session id, and set a new
one at this point, as you would when the user logs in (if they have
been issued a session id before logging on) Therefore if the remember
me checkbox was ticked, the session is found however a new one is
immediately issued and saved in case the old string was compromised.
It all sounds like added hassle but these measures go some way to
making it easier to avoid session fixation attacks.

On May 3, 1:01 pm, Mike <m... [at] mjfcadsolutions.co.uk> wrote:
> Oh no another question on login scripts. Sorry but I just wanted to
> check if the way I propose to do it would be acceptable...
>
> User's details are stored in a database.
>
> User logs in with username and password.
>
> Database is checked for match, if ok then store a random string to a
> session and the database against that user.
>
> If they checked the "remember me" box then the string is also stored
> to a cookie.
>
> Then on every page that requires you to be logged in, it first checks
> that the session exists, if it does then look for it in the database,
> if not, it checks that a cookie exists, if not go back to login. If
> cookie exists, then store the cookie value to the session string.
>
> Then try to find the session string in the database, if it does then
> thats that user and you can get details.
>
> Sound about right??
>
> Cheers
>
> Mike

i should have said session_regenerate_id() is what you call to reissue
a session id when reauthenticating/logging in etc... (if one is
already present)
and dont allow php to send session_id inside the url or in forms, so
turn off this ability inside php.ini:
session.use_only_cookies = 1
session.use_trans_sid = 0
and maybe change the session.name as well, although of course this is
just window dressing and no real security