RE: [PEAR] New features in Auth

Hello Marcus, Your idea's sound fair enough. I'm not involved in the Auth package at all but I've started using it myself recently and I've looke dinto the code to see how it works. Let me respond to the issues you mention ========================== Avoid session hijacking ========================== Hmm I never knew that was possible. Anyway, currently the system is set up to 1st check wether someone is logged in, and only if that is not true it will try to log you in with the specified credentials. And checking wether you are logged in means you need to start the session. It might be possible to check wether the credentials are specified and checking wether these are correct before checking wether someone is allready logged in allready, but it would not be as simple as adding a $authObject->setStartAfterAuthentication(true); I think it would need serious changing of all modules (tear apart credential checking and actual logging in, so credential checking can be done before session_start and logging in after), so I don't know how big this issue really is. As for system generated session_ids. I don't know how you want to distinguish between both. One way would be to actually store nothing in the session_cookie expect for the id, and save all additional information in a database table. That way one can spoof a session_id, but since there is no corresponding db-record it won't help. ========================== Register user's IP in session ========================== If I'm right this feature allready exists. The latest version I see in CVS has advanced scurity, which can be enabled with setAdvancedSecurity(true) Maybe this gives some idea's to any of the 3 maintainers of the Auth package. Herman -----Original Message----- From: Marius Mathiesen [mailto:marius@friskbris.no] Sent: Tuesday, February 24, 2004 13:21 To: pear-general@lists.php.net Subject: [PEAR] New features in Auth Please forgive me if this message is sent to the wrong address... The following is a few suggestions for security improvements in the Auth package. I've been using Auth in my latest project, and we recently had a security audit performed on the solution as security is a major issue. The audit came up with a few points that could/should be possible to implement in Auth: ========================== Avoid session hijacking ========================== There should be a means to ensure that sessions are only started after successful authentication. The way Auth works today, the server sends a session cookie to the client before authentication. This means that a session hijacker could get a valid session identifier by requesting a page that requires login, then catch the session id from the request and use this to lure the user into logging into the server using the supplied session id (eg using the HTTP TRACE vulnerability). Given that the user logs in, the hijacker would know the session id - thereby letting him access the server. If, however, the session id is only sent after successful authentication, there would be no way for a hijacker to obtain a session id without authenticating with the server himself. An additional (required, really) measure would be to ensure that only server generated session ids are accepted. Depending on your PHP setup (session.use_only_cookies, session.cookie_secure) you could produce a session id yourself in one of the following ways: POST /someurl.php HTTP/1.0 Cookie: PHPSESSID=MYKEY or GET /someurl.php?PHPSESSID=MYKEY Either way, PHP/Auth would use MYKEY as the session identifier (Set-Cookie: PHPSESSID=MYKEY). To get around this, there should be a mechanism to only accept valid session ids (that are actually generated by the server). ========================== Register user's IP in session ========================== Another security measure would be if Auth stores the IP address in the session/Auth object and only allows access to the session. This way, a user would have to spoof the IP address as well as get hold of the session id to gain unauthorized access. This would make it a _lot_ harder to hijack a user's session. In combination with secure-only session cookies this would be a great security improvement... ========================== Suggestion ========================== All of the above could be implemented as extra methods that need to be called explicitly: $authObject->setStartAfterAuthentication(true); $authObject->setAcceptValidSessionsOnly(true); $authObject->setAllowOriginatingAddressOnly(true); -- Best regards, Marius Please note that all email to this address will be scanned for spam. -- PEAR General Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php