I don't know how many of you used PHPLIB (http://phplib.netuse.de) but before session support in PHP4 it was rather impressive session/authentication code. I remember long discussions on the PHPLIB mailinglist about what mechanism to use to get the most secure way of logging in. In PHPLIB it boils down to a combination of MD5, javascript and PHP code (see crcloginform.ihtml in PHPLIB). Is the current Phortify authentication/session scheme as secure as possible? Would it make sense to have a look at PHPLIB to understand how they did it and possibly increase security without reinventing the wheel?
Another nice feature of PHPLIB was the ability the have a fair amount of authentication granularity , e.g. you could specify that John Doe - as member of a certain group - would only be allowed access to certain pages. This is something I would like to see in Phortify hopefully extended with even more granularity. Off course this means that Phortify would have to include sessions also.
What would you think of a model that focuses on 2 realms: views & actions. E.g. a content management system will have users with view access to certain areas only (you don't want CNN's weatherman to fool around with articles about the US election troubles). And then you allow the Asia weatherman to make {new, change, modify, delete} actions to Asia's weather only.
With sessions and a DB this is doable and allows you to make your authentication as granular as you like.
Thanks for your time,
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What's wrong with just using session's as way of authentication? Make up good way of assigning unique session id, make them about 64 bytes long and just
use that. All we need to store in the session (on the server) is user_id. Everything else could be determined from database.
I think one of main feature of phorify would be ability
to create groups, and assign user one or more group. We can also have feature that associates groups/users to certain allowed services. But also allow user of phortify to completely ignore it because some people dont care
about such thing.
I should go ahead and start implementing some of this
administrative features. :)
What are your thoughts on the interface of the phortify?
Class based?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fully agree that a session_id in a cookie is enough. My concern is about the *way* you send the session_id to the client. If the unique session_id is 64 bits long or even 640 bits long and you send in clear text than I do not consider that secure. The PHPLIB community has done a lot of thinking about how to get that session_id securely transmitted to the client such that if the cookie were intercepted by a malicious party, it would not allow the malicious party to take over the session of the bonafide user.
That's why I referred to the MD5,Javascript,PHP way the PHPLIB community has addressed this issue.
Regards,
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well here's a idea. Session ids could be stored in the
database with their corresponding IP address that
was used to create the session_id. Then you dont have
to worry about session hijacking. But this also means
once user gets new IP address, user loses the session.
I might be missing something, but I dont really see
any other easy way to guard against session hijacking.
Do you know what PHPLIB does? I haven't used it and
I dont know how it does it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I posted in my first reply how PHPLIB does it in a secure way (look at the code in the file crloginform.ihtml). As far as using an IP address is concerned: this is not a secure way. Imagine several users using the same proxy server to get to your site.
Regards,
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't read the PHPLib code but here's how I'd do it:
The login box appears as a seperate browser window.
It consists of two frames (one of which does not display anything, the other has the info and the textboxes).
The user enters login/passwd and hits submit.
The submit button does not submit, instead it triggers a javascript function that changes the url of the hidden frame to "www.host.xx/loginrequest.php"
loginrequest.php generates a page with a javascript function called submitRequest() that is triggered onload. This function defines a variable with a unique value (based on time+something+something_random+IP of the requester... whatever)
submitRequest() does an MD5 on the password the user entered and the variable, then sends it back (changes the url of the hidden frame to www.host.xx/loginrequest.php?pass="value of the md5 computation") along with the username.
The server looks up the password for the user in question, then does an MD5 on the password and the variable it sent to the client.
Then it compares it's own result to the result the client returned, if they match login is granted, otherwise not (the server sends back a javascrpt that closes the login window, and sets a session-cookie, or sends back a message that login could not be granted)
It's important that set the session to expire very shortly after the initial client-request - using the ip-address of the client in the variable requires anyone wishing to hijack the sesseion to have the same IP (or be able to fake that they have it?).
Of course you don't have to send the MD5 in the querystring, but I don't think that it really matters - it will only be usable for about 1 or 2 secs, and only by someone having the same IP, then never again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I don't know how many of you used PHPLIB (http://phplib.netuse.de) but before session support in PHP4 it was rather impressive session/authentication code. I remember long discussions on the PHPLIB mailinglist about what mechanism to use to get the most secure way of logging in. In PHPLIB it boils down to a combination of MD5, javascript and PHP code (see crcloginform.ihtml in PHPLIB). Is the current Phortify authentication/session scheme as secure as possible? Would it make sense to have a look at PHPLIB to understand how they did it and possibly increase security without reinventing the wheel?
Another nice feature of PHPLIB was the ability the have a fair amount of authentication granularity , e.g. you could specify that John Doe - as member of a certain group - would only be allowed access to certain pages. This is something I would like to see in Phortify hopefully extended with even more granularity. Off course this means that Phortify would have to include sessions also.
What would you think of a model that focuses on 2 realms: views & actions. E.g. a content management system will have users with view access to certain areas only (you don't want CNN's weatherman to fool around with articles about the US election troubles). And then you allow the Asia weatherman to make {new, change, modify, delete} actions to Asia's weather only.
With sessions and a DB this is doable and allows you to make your authentication as granular as you like.
Thanks for your time,
Peter
What's wrong with just using session's as way of authentication? Make up good way of assigning unique session id, make them about 64 bytes long and just
use that. All we need to store in the session (on the server) is user_id. Everything else could be determined from database.
I think one of main feature of phorify would be ability
to create groups, and assign user one or more group. We can also have feature that associates groups/users to certain allowed services. But also allow user of phortify to completely ignore it because some people dont care
about such thing.
I should go ahead and start implementing some of this
administrative features. :)
What are your thoughts on the interface of the phortify?
Class based?
Rikul,
I fully agree that a session_id in a cookie is enough. My concern is about the *way* you send the session_id to the client. If the unique session_id is 64 bits long or even 640 bits long and you send in clear text than I do not consider that secure. The PHPLIB community has done a lot of thinking about how to get that session_id securely transmitted to the client such that if the cookie were intercepted by a malicious party, it would not allow the malicious party to take over the session of the bonafide user.
That's why I referred to the MD5,Javascript,PHP way the PHPLIB community has addressed this issue.
Regards,
Peter
Well here's a idea. Session ids could be stored in the
database with their corresponding IP address that
was used to create the session_id. Then you dont have
to worry about session hijacking. But this also means
once user gets new IP address, user loses the session.
I might be missing something, but I dont really see
any other easy way to guard against session hijacking.
Do you know what PHPLIB does? I haven't used it and
I dont know how it does it.
Rikul,
I think I posted in my first reply how PHPLIB does it in a secure way (look at the code in the file crloginform.ihtml). As far as using an IP address is concerned: this is not a secure way. Imagine several users using the same proxy server to get to your site.
Regards,
Peter
I haven't read the PHPLib code but here's how I'd do it:
The login box appears as a seperate browser window.
It consists of two frames (one of which does not display anything, the other has the info and the textboxes).
The user enters login/passwd and hits submit.
The submit button does not submit, instead it triggers a javascript function that changes the url of the hidden frame to "www.host.xx/loginrequest.php"
loginrequest.php generates a page with a javascript function called submitRequest() that is triggered onload. This function defines a variable with a unique value (based on time+something+something_random+IP of the requester... whatever)
submitRequest() does an MD5 on the password the user entered and the variable, then sends it back (changes the url of the hidden frame to www.host.xx/loginrequest.php?pass="value of the md5 computation") along with the username.
The server looks up the password for the user in question, then does an MD5 on the password and the variable it sent to the client.
Then it compares it's own result to the result the client returned, if they match login is granted, otherwise not (the server sends back a javascrpt that closes the login window, and sets a session-cookie, or sends back a message that login could not be granted)
It's important that set the session to expire very shortly after the initial client-request - using the ip-address of the client in the variable requires anyone wishing to hijack the sesseion to have the same IP (or be able to fake that they have it?).
Of course you don't have to send the MD5 in the querystring, but I don't think that it really matters - it will only be usable for about 1 or 2 secs, and only by someone having the same IP, then never again