Re: [PHP] Help with authentication 'design'
You may want to check out PEAR::LiveUser http://pear.php.net/package-info.php?pacid=126 http://projects.21st-hq.de/liveuser/ A very complete / multilevel authentication package. Get the latest source from CVS as the source on pear site is a bit outdated. olinux --- "Clarkson, Nick" <[EMAIL PROTECTED]> wrote: > > Hi, > > 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 ? > > Hopefully this is relevant here. > > Thanks, > > Nick > > > > > > > > This private and confidential e-mail has been sent > to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd > (registered > no. 3319027) and Egg Investments Ltd (registered no. > 3403963) which > carries out investment business on behalf of Egg and > is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: > 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail > and have > received it in error, please notify the sender by > replying with > 'received in error' as the subject and then delete > it from your > mailbox. > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Help with authentication 'design'
> 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
RE: [PHP] Help with authentication 'design'
Hi, Could you be more specific ? I thought md5 was a one-way hash, so you couldn't get back to the original string, so was secure. Do you mean anti-replay as in IPSEC anti-replay ? If so how do I build the equivalent in PHP ? I know very little about hashing, encryption etc. so any info would be appreciated. Thanks, Nick -Original Message- From: Peter Hicks [mailto:[EMAIL PROTECTED]] Sent: 18 February 2003 14:43 To: Clarkson, Nick Cc: '[EMAIL PROTECTED]' Subject: RE: [PHP] Help with authentication 'design' Nick, md5 is a hashing function, not an encryption function. You need anti-replay if you want the password transfer to be secure On Tue, 18 Feb 2003, Clarkson, Nick wrote: > Would this pass both variables in clear text back to the server ? If so > would it be better to do this; > > [cut] > > Would this then pass both variables after being hashed with md5 ? Am I > barking up the wrong tree ? Or just plain barking ;oD This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Help with authentication 'design'
Nick, md5 is a hashing function, not an encryption function. You need anti-replay if you want the password transfer to be secure On Tue, 18 Feb 2003, Clarkson, Nick wrote: > Would this pass both variables in clear text back to the server ? If so > would it be better to do this; > > [cut] > > Would this then pass both variables after being hashed with md5 ? Am I > barking up the wrong tree ? Or just plain barking ;oD -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Help with authentication 'design'
Oops, just remembered something else; are PHP_AUTH_USER and PHP_AUTH_PW
handled at the client side or sent in clear text back to the server for
processing ? Basically what I'm doing is once they are set is doing a select
from a database like so;
$result=mysql_query("SELECT * FROM users WHERE
username='".$_SERVER['PHP_AUTH_USER']."' AND
password='".md5($_SERVER['PHP_AUTH_PW'])."'", $dbconn) or die ('Unable to
execute query.');
Would this pass both variables in clear text back to the server ? If so
would it be better to do this;
$result=mysql_query("SELECT * FROM users WHERE
md5(username=)'".md5($_SERVER['PHP_AUTH_USER'])."' AND
password='".md5($_SERVER['PHP_AUTH_PW'])."'", $dbconn) or die ('Unable to
execute query.');
Would this then pass both variables after being hashed with md5 ? Am I
barking up the wrong tree ? Or just plain barking ;oD
Thanks,
Nick
> -Original Message-
> From: Clarkson, Nick
> Sent: 18 February 2003 14:36
> To: '[EMAIL PROTECTED]'
> Subject: [PHP] Help with authentication 'design'
>
>
> Hi,
>
> 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 ?
>
> Hopefully this is relevant here.
>
> Thanks,
>
> Nick
>
>
>
>
>
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
