http://www.mtdev.com/2002/07/creatin...p-login-script

if i followed that, would i end up with a secure php script?
is that really secure?
i think it has hashes... and maybe it has salts?
i dunno, can somebody please just look over that and tell me if it would really be secure? or would i have to add the things from christophers guide?
here
http://www.webmaster-talk.com/php-fo...member-me.html

or is there a better way for me to do it/someting to follow.
also though i want to be using a forum on my site, and i'm not quite sure how i will go about doing that quite yet. But if i use user ratings, lets say numbers 1-5, can i also use that for my forum? i'm not sure if i would use a program for making the forum.. so would i be able to edit user ratings in forum to match with the login for the rest of my page?
eh i hope that makes sense, it sure confuses me

ty

I could be wrong, because I don't really use PEAR, but it doesn't look like it protects against SQL injection. Unless the function quote() does it. Might be something you would want to look into.

quote protects the data. The script is fine. There are only 3 issues:

1) http://pear.php.net/package/DB says that that module has been superseded by another, so you may want to take that into account.

2) Username matches will be case sensitive.

3) When storing passwords, an un-seeded hash leaves that section very poorly protected. Better to seed it and use a better hashing algo like sha1() or hash() [I use SHA512]. Better yet is to use a different seed for each user. Much hard to crack that way.

Otherwise it's a pretty standard login methodology.

I'm currently using an approach suggested by someone on another forum. I really like it. Basically, it works like this:

1. You create your normal user table.
2. You create a userSessions table with a minimum of three fields, the userSessionId as your primary index, the userId as a foreign index, and a userSessionHash.
3. Upon every login, you check for where the email (or username) matches the password and get the userId.
4. With the userId, you find the corresponding row in the userSessions table, delete the old userSessionHash.
5. Create a new hash based on a timestamp (for uniqueness) and a salt, encrypt it, and update the userSessions table with the newly generated hash.
6. Store the hash in either a session or cookie (it doesn't really matter which) and use it to identify your user.

The benefit to this is that you aren't storing any sensitive user data in either the session or a cookie. That means no userId, no username, no email address, etc. is ever visible or accessible. The only thing you share is a temporary and guaranteed unique hash that will be discarded on the next login. If you wanted to take it a step further, you could generate a new hash on every page load rather than just on login.

Originally Posted by JeremyMiller

quote protects the data. The script is fine. There are only 3 issues:

1) http://pear.php.net/package/DB says that that module has been superseded by another, so you may want to take that into account.

2) Username matches will be case sensitive.

3) When storing passwords, an un-seeded hash leaves that section very poorly protected. Better to seed it and use a better hashing algo like sha1() or hash() [I use SHA512]. Better yet is to use a different seed for each user. Much hard to crack that way.

Otherwise it's a pretty standard login methodology.

... thats not good. eh.
i know i could fix most the problems.. but is the fact that pear is superseded going to be an issue?
what other options do I have then? i guess i'll go google some more
it's hard finding a secure one, most of them have major security issues.

Which version of PHP are you using Chris?

Originally Posted by JeremyMiller

Which version of PHP are you using Chris?

oh i apologize, forgot to say anything about that.
its PHP 5, and choice between mysql 5 or 4.1 dunno if it madders.

oh and it gives me a choice to install dsn for mysql or not...
i really have no clue what that means for me, if i should say yes or no, ect.

Go with PDO for the database connection, then. You can rewrite the methodology to use that object and have greater compatiblity. Go with MySQL 5 b/c "Active development and support for MySQL database server versions 3.23, 4.0, and 4.1 has ended."

Originally Posted by JeremyMiller

Go with PDO for the database connection, then. You can rewrite the methodology to use that object and have greater compatiblity. Go with MySQL 5 b/c "Active development and support for MySQL database server versions 3.23, 4.0, and 4.1 has ended."

umm i'm really new to php...
I was hoping i could just find one, because i doubt i would be able to rewrite it.. maybe later though, i meen i want to eventually. But I want one to lookat and use and such now, because how it is atm im not advanced enough in php to do that.

Unfortunately, unless you use a content management system, you probably aren't going to just find a login script laying around that you can plug in to anything you want that won't require any work or rewriting. I know it seems a little daunting at first, but if you take the time to sit down and learn it, it really isn't very hard. It will help you in other areas of script building as well. If you don't like web tutorials, there are a number of good PHP books that will cover login scripts. If you don't want to buy one, I'd recommend the library.

ok well i found one that started off the basics, and i've beend oing it myself.
i'll post it here i guess then when im done to make sure its safe... need to be careful about that stuff