Security update: as of 2017-10-23: The advice in this answer, while of historical significance, is completely insecure. One should never use md5 in hashing a password because it is so easily brute forced. See this answer about how to use the built-in password_* api to hash and verify passwords.
I've dealt with login/authentication systems earlier, and I find several shortcomings in this method:
- you "md5 his password, and check the database" -- this means that if a person has access to the database, he can make out who has the same passwords!
ADDENDUM (19 Sep 2015) * Look at this link. It explains all the basics, the approaches you could take, why you should take those approaches and also gives you sample PHP code. If it's too long to read, just go to the end, grab the code and get set!
BETTER APPROACH: to store md5 of username+password+email+salt
in the database, salt being random, and stored together with the user's record.
- using the 'uid' directly in the session variables can be very risky. Consider this: my friend is logged on from my browser, and he leaves for a leak. I quickly check which cookies are set in his browser, and decipher his 'uid'. Now I own him!
BETTER APPROACH: to generate a random sessionid when the user logs in successfully, and store that session ID in the $_SESSION[]
array. You will also need to associate the sessionid with his uid (using the database, or memcached). Advantages are:
- You can even bind a sessionid to a particular IP so that the sessionid can't be abused even if it is captured
- You can invalidate an older sessionid if the user logs on from another location. So if my friend logs in from his own computer, the sessionid on my computer becomes invalid automatically.
EDIT: I've always used cookies manually for my session handling stuff. This helps me integrate the javascript components of my web apps more easily. You may need the same in your apps, in the future.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…