What is Digg?Sponsored by Dragon Age: Origins
See the new YouTube feature trailer for Dragon Age: Origins view!
youtube.com/DragonAge - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
45 Comments
- craigtheguru, on 10/12/2007, -1/+3Being a PHP professional, this script is mediocre at best. Maybe it will get the job done but I wouldn't base my site on it. Then again, I want a nice OO framework so this login / session handler should be wrapped in some class structure.
- GTPilot, on 10/12/2007, -0/+1Here's a similar tutorial I wrote. Might be a little easier to digest:
http://php.codenewbie.com/articles/php/1482/Login_With_Sessions-Page_1.html - GTPilot, on 10/12/2007, -0/+1p.s. please don't 'as a professional .. blah blah' my link. it's aimed to give newer developers a place to start. :)
- Metal_Hurlant, on 10/12/2007, -0/+1I don't like to bash honest efforts, but most of the critiques are on the mark.
- IP-constrained cookies are only practical over SSL. AOL users and other setups will break you otherwise.
- pear DB is a fairly slow abstraction layer, unsuitable for high performance systems. However, if you're going to use it, at least take advantage of its prepared statement abstraction, which provides the safest way to do SQL queries (something like $db->prepare("SELECT * FROM members WHERE username=? AND password=?", $username, $password). This syntax allows for faster response if the DB supports it, and takes care of consistently escaping parameters for you.)
- It doesn't seem the system keeps track of when cookies where issued, so it has no way of expiring them. Instead, it hopes the browser will do it for them. Not enough.
- It might come as a shock, but you don't need to connect to the DB to validate cookie credentials after the initial login. Using basic crypto, you can have cookies that web servers can verify on their own with no chance of spoofing. That also helps web apps scale better, since the DB server doesn't need to be as beefy.
- using standard PHP sessions is also a problem if you ever need to scale your site beyond one web server. - buckaroo, on 10/12/2007, -0/+1I don't like the idea of putting any cleartext personal info (serialized user name) in a cookie. I use a cookie with an md5 hash (of about 5 different criteria) for authentication, and regenerate that for each request (for any command that needs authentication). I'm still new to this aspect, and made a few notes at: (let me know of any feedback)
http://www.flexiphoto.org/fpwiki/index.php/AuthenticationAndAuthorization
I also like the idea of generating one-time md5 signatures for each form that goes out (in a hidden field), and checking for that upon submission.
A great book: Essential PHP Security, By Chris Shiflett - _jinx_, on 10/12/2007, -0/+1@chriskelly
I cant neccesarily write out all the code line for line, but I can give a brief discription of why we dont do it this common way:
HTTP Response Splitting allows spoofed session handles or session cookies. Allowing javascript to easily fake sessions, so sometimes the best step is to check the db for validation after running a client side validation check. Ofcourse one big "No No" is checking the username / password first. Instead you check the password, search for u_name and compare from there.. seems small however it makes a difference espcially with SQL injection. Also ofcourse a local small SQL injectionPrevention() call may not be a bad idea in terms of checking key words like "DELETE" or "SELECT".. - rcook, on 10/12/2007, -0/+1* always salt your password hashes
* you can't lock a session to a single IP address
* store your session variables in the database, not PHP's default storage method
no digg. - Uthman, on 10/12/2007, -0/+1I've done login scripts for my sites and others sites before... but I recently redid my website and wanted secure logins. By means of googling, this article was one of the three that I based my sites new login scripts on, however it was the one which I liked the least.
- counsel, on 10/12/2007, -0/+1I would like those who are critical of a suggested method to post corrections, improvements, alternatives, or reasons for their reasoning RATHER than just say "Being a PHP professional, this script is mediocre at best" or some other comment.
You may be right, but show everyone WHY (doing so will at least cut down on the flames). - thewebguy, on 10/12/2007, -0/+0"how many people do you think use AOL these days? I don't know the stats, but I'm willing to bet that there aren't very many"
WRONG
a lot of idiots even run aol OVER THEIR HISPEED, aol is still rampant - opus20745, on 10/12/2007, -0/+0I've got a question though. It appears to me that this script is still using the default SESSION handler for most of it right? So, the actual session data is still stored in a file on disk (albeit a directory OTHER than /tmp if you're smart). Assuming that a user will not always properly logout, the sessions will be cleared from disk when the GC runs. However, this script doesn't seem to make note of the fact that your DB should have a cron or at job running which will periodically go through and check the stored sessionids, and clear out those rows for which the corresponding "on disk" session files no longer exist. Or am I missing something in which this won't be needed?
Thanks. - rydawg, on 10/12/2007, -0/+0I've developed a few web pages in my time, but I've never learned how to do secure login. This seems like a good start for me, and it fills in some of the gaps in my knowledge.
I digg it
And to reply to the AOL user guy (GamblerZG (0)), how many people do you think use AOL these days? I don't know the stats, but I'm willing to bet that there aren't very many. Anyway, I guess you could run a sanity check if you find a person's session doesn't match with their IP. I haven't thought out the details, but I'm sure you could do it. - travisd, on 10/12/2007, -0/+0>Being a PHP professional, this script is mediocre at best.
Agreed. - geeves, on 10/12/2007, -0/+0" with just a few clickitty clickitties... The end result is a lot better than these PHP scripts and much easier to use.."
yes, sounds like the Front Page of PHP Scripting...
Anyways, the script isn't horrible, yet it sorely lacking in sanity checks of the inputted username/password - spadin, on 10/12/2007, -0/+0Probably the best thing to do would be to use session cookies only. Include a script on every secure page that checks those session cookies. If you allow persistent logins then you can have the page that checks for login set session cookies for the persistent ones (by checking against the database). When you logout, have your script destroy session and persistent cookies. Wow, I'm horrible with explanations. Oh well.
- GamblerZG, on 10/12/2007, -1/+1I recently learned that AOL users may change IPs during single session, so restricting sessions to a single IP will prohobit them to stay logged in.
- ForbesBingley, on 10/12/2007, -0/+0I used something like some years ago.
As a place to start, it's not bad. But if you're going to do it, you may as well as do it right.
The problem is with programming -- like almost anything else in life -- you soon get into your comfort zone and you don't want to budge after that.
So my advice is to pass this example up and go for something that tests your mettle a little... - _jinx_, on 10/12/2007, -0/+0@gtpilot
your right, and honestly I wouldn't consider myself a professional since I have only been programming for 3 years.. however I do program php for a living. Let me rephrase my opening comment: " As a fellow php dev..." - dbr_onix, on 10/12/2007, -0/+0Erm, not tested the code, but it seems the inputs don't have quotes etc removed..
- Ben - _jinx_, on 10/12/2007, -0/+0@buckaroo
The only issue with md5 is the fact the data is not retrievable throwing away the option of spoofed attack detection. Now, I would personally use md5 on password protection and simply ask the user to reset the the password if they forget, however.. it is a bit overdone at and to much just to protect.
I unforutenly haven't worked enough with md5 hashing, and need to more, but the idea of once hashed, now locked.. is a bit bothering - exorcyze, on 10/12/2007, -0/+0So what were the other two scripts you liked better Uthman? ;)
- chriskelley, on 10/12/2007, -0/+0would be great if those who think the script is mediocre could post some links for a better process rather then just naysaying...
- _jinx_, on 10/12/2007, -0/+0Another small addition is to try this out:
$cookie_data = $handle_id;
//Setting Cookie if Validation True Based on Login
if( setcookie( "HANDLE_ID", $cookie_data ) )
{
$cookieSet = TRUE;
}
//Redirect Here
exit ( header("location: nextpage.php") );
Then Base your pages after on the $cookie
if( isset( $_COOKIE['HANDLE_ID'] ) )
{
//Go About the normal page
}else
{
//Take them elsewhere
} - _jinx_, on 10/12/2007, -0/+0That is how I do it, bascially when the session cookie changes then you most likely not supose to be on that page. With you session set cookie you can even check to make sure the login is correct based on the initial login session cookie... yea i can't explain it well either.
- tagawa, on 10/12/2007, -0/+0Here are a couple of tutorials I found interesting:
http://www.phpfreaks.com/tutorials/40/0.php
http://evolt.org/node/60384
I'm no expert so it'd be interesting to hear an informed opinion. Better still, I'd love to see links to other recommended tutorials. It seems a lot of people could do with some help here. - _jinx_, on 10/12/2007, -0/+0ok, what im saying is... when you md5 a password and it is stored in the db. The password cannot be retrieved, instead it has to be resest and you must change it again, that is ofcourse you forget the password. A great example of this is phpBB forums. Taking the password md5 it, store it and compare the md5'ed password input by the user and allow access. That is what I am trying to explain...
- ratioswitch, on 10/12/2007, -0/+0Hey "ipugh", if you think this is a horrible technique for secure logins using PHP, what would you recommend?
- ipugh, on 10/12/2007, -0/+0jinx -- in the event of them losing it, you'd have some sort of security question/answer method that would allow them to change their password.
- ipugh, on 10/12/2007, -0/+0ratioswitch -
Maybe I should rephrase-- this is not a good technique for anyone who has any knowledge of PHP. Conversely, it is great for the beginner, no doubt.
I like to make use of the session a lot more, but I am not on a shared server. I will often store several values in the session, as well as in the page that will be posted to me, and compare them for validity before I even begin to validate the user/form data. This method alone can prevent most of the brute force hacking attempts that you will receive.
Another issue I have is storing any sort of information, outside of your session id, in a cookie. While you might store something unique to identify the visitor and keep statistics, I stay far, far, far away from any names, passwords, etc.
If you're genuinely interested in some more secure methods, feel free to e-mail me at ianpugh at gmail dot com - _jinx_, on 10/12/2007, -0/+0@12_CHARS
Im talking about storing the password in md5 in the db. - ipugh, on 10/12/2007, -0/+0metal -
I agree with you 100%, except for the session and scaling.
One of the first things I did for one of my current projects is build an object to handle the session. It will store/retrieve the session information from a centralized database upon construction/destruction.
I believe I have a white paper somewhere around here from Zend that talks about them supporting storing session information in a database naively. This would solve the scaling issue. - crossers, on 07/15/2008, -0/+0yes, today we have some problems with logins and secure PHP login script is the best way to solve this problem!
http://www.shpe-sac.org
http://www.ocflex.com/
http://www.trgovinca.org
http://www.chasr.org/ - roosteronacid, on 10/12/2007, -0/+0
Disclaimer: Wrote this in notepad, and I'm pretty tired right now. I normally use the mysqli library, and PHP5 OO. - kitsched, on 10/12/2007, -0/+0The idea behind this article is fairly OK. But stick to that, the idea. Because if you're actually trying to implement this code you'll see that there are lots of omissions. Where's the _logout function? Where is the statement that inserts / updates the cookie field? I wasted half a day with this... :(
- roosteronacid, on 10/12/2007, -0/+0Let's try that again...:
session_start();
$sUsername = preg_replace('/[^a-z0-9]/i', '', @$_POST['username']);
$sPassword = preg_replace('/[^a-z0-9]/i', '', @$_POST['password']);
if (!empty($sUsername) && !empty($sPassword)) {
mysql_connect('', '', '') or die(mysql_error());
mysql_select_db('') or die(mysql_error());
$query = "
SELECT id, username, password
FROM table
WHERE
username='". $sUsername ."'
AND
password='". $sPassword ."'
";
$result = mysql_query($query) or die(mysql_error());
if (mysql_num_rows($result) > 0) {
$entries = mysql_fetch_assoc($result);
$_SESSION['logged'][0] = 1;
$_SESSION['logged']['id'][0] = $entries['id'];
$_SESSION['logged']['username'][0] = $entries['username'];
// and so forth...
}
}
Disclaimer: Wrote this in notepad, and I'm pretty tired right now. I normally use the mysqli library, and PHP5 OO. - johnnybravoh, on 10/12/2007, -0/+0Jeez why not just use an Auth library like Pears AUTH? http://pear.php.net/Auth
- barbwire, on 10/12/2007, -0/+0The bigger problem I see with this technique is the limitation of only being able to login in one browser/computer. I am more inclined to have a supplementary table of user tokens so that I can support auto login for the same user on multiple machines or browsers.
- daveb, on 10/12/2007, -0/+0In addition to what everyone else has said... this code doesn't bloody work! I'm half way through implementing it and I notice that we SELECT cookie from our DB table, but at no point do we ever INSERT or UPDATE cookie in our DB table. Waste of my time, I'm going to write my own
- wentonchan, on 10/12/2007, -0/+0@ gtpilot
Lurking, happened upon that link. I just had to register and thank you for this solution. It's rather simple and elegant for some secure login and sessions IMHO.
Thanks. - buckaroo, on 10/12/2007, -0/+0@johnnybravoh -- " why not just use an Auth library like Pears AUTH?"
One reason would be to keep the prerequisites down for an OSS package. It's one thing if I write code for a specific client, and have some say about how the server environment is set up. If I'm writing something that I want to distribute, I want to avoid having a big laundry list of "you need this package, and that one too, and don't forget that one, etc." Every item added to the list becomes one more little obstacle for a potential user/installer to deal with.
The flip side is using things that have a pretty good chance of being installed almost everywhere. "DB" is more likely than "AUTH". I have no data points to base that on, btw :-) - ipugh, on 10/12/2007, -1/+0I think this is a horrible technique for secure logins using PHP.
If you're going to take the time to do it -- do it right. - MannaPC, on 10/12/2007, -1/+0This is old and I personally think Dev Shed sucks.
not a very good tutorial either. You don't need that many functions :P - _jinx_, on 10/12/2007, -1/+0@12 CHARS
Thats exctly what I was saying... taking the HASH and comparing it to the stored HASH.. :) Atleast you understand...But yes I do this for a living ( with a toy language though ) haha..... - _jinx_, on 10/12/2007, -1/+0As a PHP dev, a highly suggested method is to do multiple login validations, client and server side if applicable. I agree this method is not bad, yet I can think of better faster and easier ways that are as much secure, if you depend on one script to check valid info on very important information... you aren't taking the right steps. For loggins, with each page impression of specific data a php validation should be ran in some manor or another.
- alexdresko, on 10/12/2007, -5/+0Ha! Microsoft Visual WebDeveloper Express 2005 (free) can do all of this with just a few clickitty clickitties... The end result is a lot better than these PHP scripts and much easier to use..
Browsing Digg on your phone just got easier with our enhancements to the 
© Digg Inc. 2009
— Content created and posted by Digg users is