Login system: security

notset

Hello,

I'm creating user login system.

When user enters valid username and password, i set $_SESSION['uid'] = $user_id;

Then in all user area pages i check if is $_SESSION['uid'] set and if this user id exists in my database.

The question: it's enough secure?
Can user (hacker) set his own $_SESSION['uid'] ?
Maybe i should use a hash with user's password or something like that?

Thank's for comments.

MarkR

notset wrote:
Then in all user area pages i check if is $_SESSION['uid'] set and if this user id exists in my database.

The question: it's enough secure?

Probably, yes. Provided there aren't any other bugs in your application.

You should still watch out for session stealing and session fixation attacks - I'd recommend:
1. set session.use_only_cookies before session_start()
2. Regenerate the session ID during login.

These two steps will make session fixation / takeover, MORE DIFFICULT. It won't necessarily help, particularly if you have XSS vulnerabilities elsewhere in your app.

Can user (hacker) set his own $_SESSION['uid'] ?

Not unless they exploit a bug elsewhere in your system.

Maybe i should use a hash with user's password or something like that?

It wouldn't be any more secure do to so (in fact, it would be less secure, as two users might have the same password).

The security of your application needs to be addressed as a whole. In particular, you must have an application-wide strategy for prevention of:

SQL injection
HTML injection (i.e. cross-site scripting attacks)

And I strongly recommend that you consider installing some prevention of CSRF (cross-site-request-forgery) attacks.

Mark

notset

Thank you for the detailed detailed answer.

MarkR wrote:
2. Regenerate the session ID during login.

When exactly: before setting $_SESSION['uid'] or after? Or no matter?

MarkR wrote:
The security of your application needs to be addressed as a whole. In particular, you must have an application-wide strategy for prevention of:

SQL injection

HTML injection (i.e. cross-site scripting attacks)

- SQL injection: mysql_real_escape_string()

- HTML injection: htmlspecialchars()

It's enough?

MarkR wrote:
And I strongly recommend that you consider installing some prevention of CSRF (cross-site-request-forgery) attacks.

What for example?

Thank's

MarkR

notset wrote:
When exactly: before setting $_SESSION['uid'] or after? Or no matter?

It should not matter, as session_regenerate_id() will copy the session contents.

- SQL injection: mysql_real_escape_string()
- HTML injection: htmlspecialchars()

It's enough?

If deployed correctly and thoroughly, yes. Personally I prefer using prepared queries and some sort of templating system respectively.

What for example?

Against CSRF? Have a look at how other people have done it.

Typically this means storing something in a hidden field that an attacker cannot possibly know - the session ID is potentially a good one.

This needs to be done throughout sensitive parts of your application. Like all of these things, thought needs to be given as to how you can reuse the code, thus enabling it in all places necessary.

Mark

notset

MarkR wrote:
1. set session.use_only_cookies before session_start()

MarkR, what to do if the user has disabled cookies in his browser? Do not allow to view my site because sessions won't work? Or check, if cookies is enabled and then set session.use_only_cookies on/off, but, when user will try to login, fail that and say, that he must enable cookies?

notset

How about this:

login.php

if ($login == true) {
    session_regenerate_id();
    $_SESSION['uid'] = $row['id'];
    mysql_query("UPDATE `users` SET `session_id` = '".session_id()."', `last_login_ip` = '".$ip."'");
}

check_login.php

if (isset($_SESSION['uid']) && $_SESSION['uid'] != '' || ctype_digit($_SESSION['uid'])) {
   $user = mysql_query("SELECT * FROM `users` WHERE `id` = '".$_SESSION['uid']."' AND `session_id` = '".session_id()."' AND `last_login_ip` = '".$ip."'");
   if ($user != NULL) {
     echo 'true session';
   }
}

And another question: if is secure to allow people to try to login as many times as they want without any "human code" (image code confirmation)? If no, what do you recommend?

Thank's

MarkR

notset wrote:
And another question: if is secure to allow people to try to login as many times as they want without any "human code" (image code confirmation)? If no, what do you recommend?

I recommend that you don't use CAPTCHAs anywhere on your site until you have a known problem with people creating bots hitting it.

They are extremely annoying for users, and (relatively) complex to implement.

If you've got a problem with bots trying to brute-force the login, you should rate-limit it by IP address instead (say, a maximum of 5 login failures per IP per minute allowed).

But all these measures should probably be taken retrospectively, i.e. AFTER you know you have a bot problem.

Someone will require some level of effort to create a bot smart enough to outwit your CSRF protection measures and other basic stuff - a "cookbook" exploit may not cut it (Although there are an increasing number of lame script kiddie tools).

In any case, if you record registrations and logons by IP address, it should be easy enough to retrospectively report on these attacks and delete all users / things created by them - with a fixed amount of effort regardless of the number of users created.

Mark

notset

3-4 mysql queries during login - it's normal or too much?

MarkR

3-4 is perfectly fine - I wouldn't be surprised if my authentication system requires 3 on every page (even if it doesn't do anything else)

Mark