tags:

views:

129

answers:

4

Hi,

I'm writing a login system for a website I'm building.
Here is the essence of how I'm implementing the login system:

I have two tables: users, and sessions.

   users: uid | uname | pass
sessions: sid | uid | ts | ts_expires

So the user enters a uname/pass combination.

  • if the combination is incorrect, I redirect to a "bad auth" page.
  • if the combination is correct, I:
    • generate a random sessionid (sid)
    • insert a record into sessions associating that sid with the uid of the username supplied.
    • set a cookie named sid with the value of the random sid just inserted into sessions.

On each page that needs the user to be logged in, I check:

  • whether the cookie is set
  • if the sid is valid

So my questions are:

  • What could be potential problems with this mechanism?
  • How should a good login system be implemented?

Cheers!
jrh

PS: I don't use SSL secured login yet. So that is the only problem I spot, as of now. And oh, I use php and mysql, if that is relevant.


EDIT: I store the passwords not in plaintext, but as an MD5 of the username concatenated with the password.

So, pass = MD5($uname.$pass), so to speak.

+4  A: 

Hash that password, with a salt! Use a strong hash like bcrypt. If you have to use MD5/SHA use a technique called stretching and hash it's hashes several thousand times. The user won't care if it takes a second to check his/her password instead of 1/1000, but a brute force cracker will.

Record attempts and prevent brute force attempts.

Be very cautious of where you store the user's credentials once he logs in. You don't want them changing it.

And use SSL!

Malfist
+1 for record attempts
Here Be Wolves
I also suggest that you manually encode all the data sent with RSA both on client as well as server side for additional safety. You never know what that hacker might use your WoW item stats for.
Kornel Kisielewicz
A: 

It's generally good practice to store the password as a salted one-way hash of the actual password rather than storing it as cleartext. You haven't stated if you do that or not, but if not, do it.

Make sure that the login has a timeout period, so it won't last forever.

Make sure that the cookie is deleted on logout.

Don't forget that the user may be logging in from a public computer and that storing login credentials as a cookie could result in a subsequent user gaining access through an abandoned session.

Adam Crossland
w.r.t the last point (public computer): I can only warn the user not to use the "remember me" feature on a public computer, right? I could try binding the sessionid to a particular IP so that the sid itself can't be stolen and misused..
Here Be Wolves
There's not a whole lot that you can do to protect the user when they are logging in from a public computer aside from emphasizing the need to explicitly log out of the app when they are done and having the session timeout after a very short time. Certainly, you would want to disable any "remember me" functionality as well.
Adam Crossland
+1  A: 

To slow down a brute force attack, put in a forced delay after a failed attempt; that is, if someone gives you the wrong password, wait three seconds before displaying the next screen with "password failed".

Dean J
will that potentially slow down my website?
Here Be Wolves
Not really. Not if it's a sleep. It won't consume clock cycles, only delay the webpage from loading for that one person.
Malfist
+1  A: 

Designing and implementing a secure, robust, usable login system is actually pretty difficult to get right on the first try. Pages upon pages have been written about this topic - far too expansive to treat properly, here.

A good starting point is www.owasp.org. Then engage someone you work with that is knowledgeable about security, contract with a security company (such as www.matasano.com, veracode.com, or neohapsis.com - I've worked with all three, and all three are very good), and/or ask questions on security mailing lists (like the web application security list listed on securityfocus.com).

atk
Very difficult, agreed. It is nearly impossible to think of and account for all of the contingencies.
Adam Crossland