Page 1 of 1

Session management and secure aspect

Posted: Mon Apr 05, 2004 9:22 pm
by Pozor
Hello,

I redo my session management. Now first to my old system.
It works very well, with or without cookies (depends what the user support). But i haven't thought to
any big secure aspects.

Old system:

It is a DB based system with dynamic generating session ID (md5). I do NOT use any PHP session function. And i programmed it as a class.
Ok i know its not the fastes way with classes, but for this purpose its enough fast.

I wanna do some new function for more security with the session.

My idea is:

i redo my session class with followed aims:

4 different work scenarios:

session: normal without cookies (over url append like the old system)
session: normal with cookies (like the old system)

session: secure without cookies

additional check (and save in DB) of:

IP ($_SERVER['REMOTE_ADDR'])
Useragent (Browser) ($_SERVER['HTTP_USER_AGENT'])

Session: secure mit cookie
like session secure without cookies but with additional:

set a random hash (md5 like the ID)
this hash is only valid for one reload
everytime when the session is called, it's generate a new random hash
to protect the session id.
(it is save in the db for sure)

Information for checking the validity of a session:

Useragent:
It is not a very save, because it has many similar browsers in use

IP:
Problemactic is that users behind a router or something like that,
have the same IP, and the IP can change dynamically
-> session's dead! (if ip changes)

SessionID per URL:
esay to steal/abuse, but nescessary for user who dont support cookies
(only used when cookies doesn't work!)

SessionID per Cookie:
better protection as per URL, but still not very save (easy to cpoy a cookie)

Session Cookie with dynamic generated security Hash:
improves the protection a lot. The "bad guy" has to get both cookies,
and must be faster then the user clicks again...
the security hash changes with every reload/load of a page


What do you think about this beginning?
Any better ideas?
Critics?
All welcome!

greez Pozor


PS: sorry my english isn't the best... i know (i'm still working on it)
Stillstand ist Rückschritt!

Posted: Mon Apr 05, 2004 9:29 pm
by phice
Gehen Sie aufhebt rückwärts!

haha.

Posted: Mon Apr 05, 2004 9:34 pm
by Pozor
Hello,

sorry i'm from Switzerland, and i translated this from an other post (in a german forum and i forgot this...)

its like no movement is step backwards...

greez Pozor

Posted: Mon Apr 05, 2004 9:42 pm
by Pozor
Hello,

This is a translation from one of my threads in a german forum, but there it has not many people, who are able to give some good advice (or sophisticated solutions)

greez Pozor

what else?

Posted: Tue Apr 06, 2004 3:21 am
by djot
-
Hi,

What else do you think you can do?

Or what else u may control?

session_id, cookie, ip <-> check with server DB

There is nothing more, except HTTPS or (useless) browser-check.


Suggestion:

But what I am thinking about when coming to this problem was to use a new session with each transaction. Session IDs than would rather be TANs than IDs.

Advantage: No ID hijacking or cookie stealing.

Problems:
- more DB load
- User may not use the browsers' back-button, cause the back-ID is than too old. (To overcome this, it is possible to save a fall-back point or a last action taken link; for sure to store 2 IDs - the old and new one)


Any comments to this?


djot
-

Posted: Tue Apr 06, 2004 8:59 am
by Pozor
Hello,

i would only save the hash (dyn. protectiting id) when cookies are supported, so it shouldent be a problem with a back button or slow laod and then the user make a reload (cookies will be set with the header info who are first).

greez Pozor

PS: it seems to be that nobody have a better solution for this problem without ssl...

Posted: Wed Apr 07, 2004 5:03 pm
by Pozor
hello,

Only change the sessid without a security hash.
Maybe i should make a kind of stack (size of 3), then the backbutton action is suported for url append (min size 2).

whats about this solution?