0

I'm creating a secure login script at the moment. The script works like this:

1) On page load, a session ID is generate (session_start)

2) User enters username and password

3) Script clean the user input.

4) Username and password are checked for match in database,

5) If successful, a new session ID is generated, and the user is logged into their account.

Upon the user logging in, how do I retrieve all relevant information about the user from the database? I'm currently storing the user ID (an auto_increment field) in a session, and am using this search for the relevant details in the database?

Is this secure?

user826855
  • 586
  • 1
  • 7
  • 18
  • Use OpenID instead. That's safe and very simple to implement thanks to very good/easy libraries like for example LightOpenID!! – Alfred Jul 31 '11 at 13:45

2 Answers2

1

There some potential issues:

3) You don't need to "clean" input. Instead, use prepared statements and encode input, for example with htmlspecialchars when you're outputting into an HTML document.

4) You shouldn't store passwords in the database, but salted hashes.

5) You don't need to generate your own session IDs. Instead, just set $_SESSION['logged'] to the user's name and test that later on.

By the way, it's not a good idea to implement password management yourself - why don't you use OpenID? Also, make sure to use SSL to prevent local attackers from simply grabbing passwords and session IDs.

Community
  • 1
  • 1
phihag
  • 263,143
  • 67
  • 432
  • 458
  • @user826855 That is not necessary when you're using prepared statements. The simpler the code, the less chances of bugs. – phihag Jul 31 '11 at 13:25
  • 3) I'm cleaning the input to prevent sql injection as I am searching the user's username and password that they input into the form in the database. Surely this is correct? 4) I'm not storing the passwords as plain text, but am storing a hashed version of the password. I'll take note of what you said, and will include a salt. How does salting work? 5) I'm generating a new session ID after the user has logged in, as I have read this will help prevent against session fixation. Regarding the "Logged" session, is it ok to just store the users username as a detection that the user is logged in? – user826855 Jul 31 '11 at 13:29
  • 3) "Cleaning" inputs is rarely a good idea. It's very easy to miss important details of character encodings and DBMS dialect. I don't know how I can say it more clearly: **Use prepared statements**. 4) You pick a random value and construct a special hash function with it, for example `hash($random_string . $password)`. More details in [this stackoverflow answer](http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190). 5) Session fixiation is only an issue if you use non-cookie-based authentication. Generating a new session is fine though (continued) – phihag Jul 31 '11 at 13:40
  • Continued: Yes, data stored in `$_SESSION` [cannot be maniupulated by the client](http://stackoverflow.com/questions/6643584/which-of-those-can-be-manipulated-on-client-side). – phihag Jul 31 '11 at 13:44
0

Will your login form submit over SSL? If not then unless you implement some client-side HOTP routine then the password will be sent plain text. This is not secure.

Nev Stokes
  • 7,531
  • 4
  • 39
  • 43
  • So am I ok to store the record number of the user in a session? – user826855 Jul 31 '11 at 13:51
  • My point isn't really about the session — it's about how you submit your username and password in the first place. Whatever you store, make sure you have some extra security layer to help prevent session hijacking. – Nev Stokes Jul 31 '11 at 14:01