> I've searched the archives, bit it's not helping me much purely because it's > not specific PHP code I'm after, but rather help with a login system design. > So far I've got a PHP_AUTH based login which checks against a MySQL > database, and if the user's details are correct it updates the database with > their IP and login time, then creates sessions variables for their username > and security level (for admins, mods etc). However, the more I read, the > more I worry about security, so I want to try and get this as good as I can > possibly get it with security my main concern. What I hope to achieve is > some reusable code. All the tutorials and sample code I look at say don't > use this in a production environment because it's not secure. When I'm happy > with what I've got I'll make the code available, hopefully this will be a > joint effort and any credit will be given. > So far the steps I have are; > > Set $auth to false > Are PHP_AUTH_USER and PHP_AUTH_PW set ? > Yes -> Connect to database > check user/pw exists in database > if they do then set $auth to true > > Is $auth false ? > Yes -> Display login box with header(); > > No -> update database with ip and time > create sessions variables > forward to next page > > I'm after two things; ideas for a better (more comprehensive) design and > potential security holes. Are sessions a bad idea ? Should I store them in > my database ? Is the initial HTTP authentication a bad idea (because of > either security or browser compatability) and can I make the HTTP > authentication more secure ? Should I stick with a regular login form ? Is > checking for a username session variable on each following page enough ?
I would recommend not using the client's IP address for any kind of authentication. It is well known that some large ISPs (AOL) use proxies so one client could have two different IP addresses in two subsequent requests. Sessions are not a bad idea. The default file storage works well unless you want them in a database for some reason (possibly a server farm with load balancing and you don't want sticky sessions). If you are worried about sending passwords as plain text you could either use SSL or JavaScript to create a hash of the password instead. This has been discussed recently. Client authentication is the real risk here. Using the built in session management will set either a cookie or URL variable that is used to lookup session information. I would recommend using this method and combining it with another check of some sort. That way if cookies are stolen or a URL is e-mailed or bookmarked with a PHPSESSID in it, you still have a chance of avoiding a client interfering with another client's session. One possible way of doing this would be to create a sort of fingerprint (like an md5 hash) of the client based on the HTTP headers that the client sends. Then store the fingerprint in a session variable and check it on each request. User-Agent and Accept-Language might be good choices. Here are some others to choose from: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3 HTH, Brad -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
