On Monday, February 18, 2002, at 09:17 PM, Phillip S. Baker wrote:
> Now first question is - how secure is this? > > Second question - what is a better more secure way to handle this. Then > most importantly where do I get information on how to go about doing > that? > I know nothing about sessions and would need some good links for that > arena. > > Also I do not know much of anything about Object Oriented Programming. I'm in the exact same shoes as you are. I just did the exact same auth scheme, pretty much (is this the standard auth scheme?). Also, I'm sure there's a better way I could be doing this. Thirdly, I don't know much of anything about OOP either but I'm trying to learn. I was in a bookstore today, and saw a brand new book: the Visual QuickPro Advanced PHP guide or something. It looked excellent -- a whole section on "object oriented programming" within PHP (sic quotes). I'd like to pick it up for more info, and maybe you should look into. Sometimes Amazon.com has like a 20 page excerpt of the book in PDF I think. Anyways, the important thing is to remember that HTTP is a pretty insecure protocol if you're not encrypting your data. Make sure that your password is encrypted by PHP before you send it to the MySQL server. There's an open source (free) program used for diagnostic purposes that can be pointed to any server on the internet, and monitor port 80, so anyone see exactly what GET, POST, and COOKIE data you'd be sending along with your authorization request. I think the standard way most do it is to store the password encrypted in the database too, which means you can't email the password to someone if they forget it -- it has to be changed. The other thing to do is add an exit() function immediately after your header() redirect. I did this, because if you don't, the user agent doesn't necessarily HAVE to get redirected. Think of the redirect as a suggestion. Sure, most browsers will comply and the user will never see the data. But the data is still sent, and if the user agent is a Perl script or something then of course it will only automatically redirect if its author has programmed it to do so. Using exit() will prevent the rest of your script from executing, which means that the rest of the page will not display. Ummm... well, there's probably more security-conscious people on this list than me who can come up with more. Just think about the logical HTTP exchange and where data might accidentally leak out, and you'll probably cover most of your bases. Erik PS: I'm assuming that SSL is beyond the scope of your application. Otherwise, consider it. ---- Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
