views:

90

answers:

4

My question is about creating a secure log in routine. After comparing the user name and password to the stored values I set a session variable called logged to true. Then as the user surfs around the web page I just check the logged variable for true or false to determine if the user should have access.

This is my first time creating something like this. Is this secure? I feel like there is something else that I should be doing to make sure that users are valid.

A: 

You are probably going to want to store the username in session as well in order to properly customize any pages for the user. What you described is "secure" but the security of your application is hard to assess without knowing what else you are doing.

Chris Thompson
+1  A: 

Sure, it's secure but there are precautions you should take to prevent insecure circumstances/attacks.

There is nothing wrong with the mechanism you've described, at all. But the implementation is incomplete/unspecific. You have to consider password storage, and the procedures you'll use for login.

In response to a complaint, here's some issues OWASP brings up about authentication/sessions.

1. Are credentials always protected when stored using hashing or encryption?.

Yes, store your users passwords as salted hashes.

2. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?

No, those functions should be protected by a security question/email link.

3. Are session IDs exposed in the URL (e.g., URL rewriting)?

Nope, they shouldn't be.

4. Are session IDs vulnerable to session fixation attacks?

Nope, don't allow users to set their session id through any means besides login.

5. Do session IDs timeout and can users log out?

In cases where the user hasn't otherwise specified "to stay logged in for two weeks", sessions should expire soonish.

6. Are session IDs rotated after successful login?

Yes, using session_destroy() and session_start() will accomplish this.

7. Are passwords, session IDs, and other credentials sent only over TLS connections?

Sure.

Ultimately, you have to consider the kind of data you'll be handling. Never allow someone to gain access to a user's password, since it could compromise their data elsewhere. But, if you're running colorakitten.com, don't loose sleep over the possibility of hijacked sessions: "Oh no, someone hacked my account and discolored my kittens."

Read: http://stackoverflow.com/questions/328/php-session-security

arbales
-1 That answer is horrible. That guy has no idea what he is talking about, and yes i gave that answer a -1 as well.
Rook
To be specific that answer is clear violation of the OWASP TOP 10 for 2010 A3: broken authentication and session management.
Rook
No, the answer isn't horrible. It's not broken either. Using the PHP $_SESSION function and checking it against an IP is just fine, especially over SSL.
arbales
+1  A: 

Anyone that gets your session cookie, is able to login as you. If you bind a session to an ip address, it's a lot harder. But this can give you problems with people that have changing ip addresses. It's up to you to decide if that's worth the trouble.

Ikke
Ikke's right. It's always up to you.
arbales
+1  A: 

Hello doodle,

If you're not handling any kind of sensitive information and just trying to provide a personal user experience, what you're doing is fine. However, if you're truly concerned about security, there are several other approaches you can take. The first is to create a database table called "user_tokens" or something similar. When a user signs in, create a random key and store their ip address in the table associated with the key. Also, store that key in a cookie on the clients' machine. Anytime they try to do something sensitive, you can compare their ip address and key of the cookie to that of the database.

Research a little bit into Cross-Site-Scripting (XSS) and session hijacking. The method I've outlined above will really cut down on this.

DexterW
Although it'd work, generally avoid the extra database queries. Instead, stick this information into a cookie and sign it. Don't take my word for it, take Cal's. http://www.youtube.com/watch?v=i6Fr65PFqfk
arbales
The information is in a cookie... that's what is being used to compare to the values in the database. Cookies are not always secure, as they can be stolen. If you're dealing with super sensitive information, it's worth the extra query.
DexterW