Log in system

[vineld]

I am having second doubts about my login system regarding safety. What I do is this:

 

1. A user signs in with username / password

2. If correct, set session id and log in status in database

3. A session cookie is created storing user id and session id

 

When checking if the user is logged in:

 

1. Check if the session cookie exists

2. Read user id and session id from cookie

3. Check if user and session couple is logged in according to the database

 

Is this secure or is it too vulnerable? The cookie can of course be faked...

[Third_Degree]

Session fixation.

 

Keep working...

 

Edit: in all honesty though, it's pretty solid.  just when a user logs in, anyone can be on their account provided they access the sid.

[mmarif4u]

The flow you mentioned is fine.

But the question about vulnerable is related to your scripts. That how you design and write it. How secure it is from outside attackers. By using normal security implementation will make your site secure.

Like, securing database querying will make your code hard to broke.

A lot more things can be considered here, all depends on your code implementation and design.

[vineld]

Thanks for the comments. What would be the best way to modify my logic in order to protect myself from session fixation? I wish to make the login system as secure as possible without making it difficult for the users. Storing the session id in the cookie may not be the optimal solution but at least it's way better than username and / or password which I have seen quite a few people do 

 

I feel that my session handling is the weakness of the system. The password handling should be fine and otherwise I usually stay protected against sql injections, xss and mail injections.

[Third_Degree]

You could try an ip or ip range check.  But if you're sure you've coded securely against xss, you don't have to bother.  Personally, I like hashed, salted cookies. yum...

[vineld]

I always log the IPs in various situations anyway in order to make for example admin areas safer and to stay on the watch for attacks and for a few other purposes but I don't like the idea of using it to directly restrict access for regular users since it imposes several problems.

 

The issue is not really the log in itself which should be secure enough (I always use sha1 and double salts) but mainly the session handling. The way the system is built currently someone might be able to rob the user of its session and pose as them although it is not that likely I guess.

 

What do you mean by hashed cookies btw? I can't really hash the session id?    Well, I guess I could but what would be the point? As long as I steal the cookie it doesn't really matter what format the data has as I will still be identified as you?

[vineld]

I would like to reawaken this thread once again since it is an interesting subject to discuss I think. Security is far from good at many sites I've encountered over the years.

 

This log in script of mine, which, in my defence, was written a while back, is troubling me. What is troubling is that I don't really know what my train of though was back then.

 

Why do I set a cookie when I might as well store the values as session variables? On the other side, why do I even use sessions when I might as well just generate a random id for the cookie? It apparently makes no difference to my script.

 

The problem now is, if someone steals the cookie, they are obviously able to pose as the user.

 

Would you say the system is sufficient or what would you do in order to improve it and make it more secure?

[WolfRage]

I may have gone a little extreme with my session management class. But my class resets the users session prior to directing them to the real login along with that it passes a coded url to ensure they have been assigned a new session cookie. I then have the user login. If the login is correct the user proceeds to another section which will reset the SID agian. I also pass them another cookie with a salted hash that is tied to there session. Then the final pass is to another coded url to ensure they have everything corect. Once they are in they recieve one more hashed cookie which is tied to there session. I figure this way I know I have the same user along each path and that user was given three cookies but at different times throughout the login process. It is highly unlikely that someone will be able to fixate the session and jack the other cookies too, especially in a SSL enviroment. However I believe that passing these even in a non SSL enviroment still offers a higher degree of security. By coded url I mean that the url includes get variables that are hashed and randomly generated but tied to the session.

Additionally the class also maintians that the useragent should not change. The IP is tested and does throw a flag if it changes, but if this change is frequent then the class ignores it.