Website logged on user security approaches

For everything that's not in any way related to PureBasic. General chat etc...
Dare
Addict
Addict
Posts: 1965
Joined: Mon May 29, 2006 1:01 am
Location: Outback

Website logged on user security approaches

Post by Dare »

Looking for some thoughts from people who work with websites.

I am looking for a way to make improve security (for logged in users) using serverside script (traditional ASP), cookies and perhaps IP addresses.


If you are interested, this is what I currently do (if not interested, just read the last few lines, and if not interested at all - I'm deeply cut. :)):

When a user logs in to a site, the following is done:
  • 1: A decent sized random number is generated.
    2: A field in the user record in the db is updated with this number.
    3: The user record ID from the database is embedded into the number, digits scattered throughout using a another random number and a simple formula which also generates a "key". The key is prepended to the string.
    4: The string is sent to the user as a session cookie (it expires if the user disconnects or times out, or is forced to expire if the user logs out)
    5: When the cookie expires the special field in the user record is blanked.
    6: If a user logs in and the special field is not blank the field is blanked and the user chucked out - can retry login after a short time, by which time the first user is hopefully ejected (see below) and one or both kick up a stink :)
When users browse "members-only" pages, the cookie is requested and the following is done.
  • 1: No cookie, user chucked.
    2: The key is used to seperate the ID and the random number in the cookie data.
    3: The record associated with that unique ID is retrieved from the DB.
    4: If the ID is invalid, the user is chucked and the cookie removed.
    5: The field in the record is checked against the random number, if different the user is chucked (blank fields being unequal also see the user chucked)
    6: Session cookie is updated to expire after "n" minutes from this event.
The cookie data, btw, is obsfucated using a self "encrypt/decrypt" algo similar to the one I posted somewhere on these forums.


(Some other standard stuff is done such as logging)


This has been okay so far, but now I want to make it more secure.



So ...



Any good ideas or thoughts on how to improve security (I am limited to using cookies and/or IP for maintaining state).

I don't have a clue as how to do this outside of my own efforts (eg, using approaches like the above) and maybe using SSL. Also these are not my servers, but are run by hosting companies who don't like executables being installed - understandably.


(I know this has little to do with PureBasic, save that the website is administered by people using specialist clients written in purebasic, but I am hoping some of you IT gurus or webmasters will humour me anyhow)


Edit: Some editing to reduce verbosite (really!) and deobsfucate this post.
Dare2 cut down to size
Straker
Enthusiast
Enthusiast
Posts: 701
Joined: Wed Apr 13, 2005 10:45 pm
Location: Idaho, USA

Post by Straker »

Check this out:

http://www.technicalinfo.net/papers/Web ... ement.html

Seems pretty complex and secure already. Does your website hold nuclear launch codes or something?
Image Image
thefool
Always Here
Always Here
Posts: 5875
Joined: Sat Aug 30, 2003 5:58 pm
Location: Denmark

Post by thefool »

straker:
Image

Send me 150$ and i'll take these naughty pics of you away!
btw is that your real hair?
Straker
Enthusiast
Enthusiast
Posts: 701
Joined: Wed Apr 13, 2005 10:45 pm
Location: Idaho, USA

Post by Straker »

:shock:

You found me out!
Image Image
thefool
Always Here
Always Here
Posts: 5875
Joined: Sat Aug 30, 2003 5:58 pm
Location: Denmark

Post by thefool »

yeah well, it was not that hard. I mean you got a website and all that!
Dare
Addict
Addict
Posts: 1965
Joined: Mon May 29, 2006 1:01 am
Location: Outback

Post by Dare »

lol.

Hi Straker, thanks for the link. The way that article words things has triggered an idea.

Straker wrote:Does your website hold nuclear launch codes or something?
:) Nah, just sensitive information about members (contact info, etc) and some documental material that businesses would probably prefer not to send via the classifieds. :)

Straker wrote:Seems pretty complex and secure already.
That is comforting, given there are a few other hoops to jump through as well.

I am just not too confident about anything I create. :?
Dare2 cut down to size
Straker
Enthusiast
Enthusiast
Posts: 701
Joined: Wed Apr 13, 2005 10:45 pm
Location: Idaho, USA

Post by Straker »

I forgot to mention before, for secure pages, in addition to sessions, we also use a function (in PHP) that checks the domain of the referring URL (the previous page). If the domain is not my domain, then they get kicked.

Essentially, this means they must navigate secure pages starting in my domain.

Cheers
Image Image
Pantcho!!
Enthusiast
Enthusiast
Posts: 538
Joined: Tue Feb 24, 2004 3:43 am
Location: Israel
Contact:

Post by Pantcho!! »

dare: man your post is long...

I can suggest this (it can be stupid but thats what i think):
If you are going to make it based by cookies then i suggest in the DB user field where there is the random genrated number you can do 2 things.
1. create a KEY which holds: UserIP,User Session TIme.
2. create another table with 4 fields : KEY,Session Time,UserIDInDB,UserIP.

the option 1 contains your encrypted cookie string , when ever you unencrypt the cookie , if the session time is over just clear the cookie and KEY field in user DB and kick out user.
your site will need to auth a login each time when the key field in the DB is empty/session time in key expired/invalid IP in the current cookie (diffrent pc/browser).

the option 2 contains a KEY which leads you to the user where it is changing all the time (each new key assigned with a now login)
so trying to decrypt wont do good since you can do a random encryption (selecting diffrent encryption each time a key is created but with ID to know which encryption it is [encryption in encryption] )

the option 2 is much better because if a smart hacker enabled to crack your encrypted string in option 1, he can try to mess up stufff...
same kicking rules go to option 2.

good luck, hope i helped..
Post Reply