melbourne chapter

I have recently started using “Challenge/Response” security pattern for my web applications. The main cause to move to this new architecture was to provide a more robust secure entry point to my application and employ some smarter methods of authentication.

The Challenge/Response pattern allows the user to be logged onto the system without ever sending their password in clear text to the server. It does not require the infrastructure of an SSL certificate for secured transmission.

The user is issued a challenge “hash” string and creates a response “hash” string that comprises of the hashing of the original challenge hash concatenated with their password. The password is removed from the form at the time of form submission by their clients browser and submits the new response hash string to the server (through a hidden form field), along with their username (without their password). This response is compared to a server-side reconstruction of what the valid details are and are then compared.

Additional to the protection from anyone tapping into the HTTP requests, the server now controls the issuing of these challenge keys and we are now provided with a number of additional security options and validations we can play with;
- Setting a expiry timestamp for the challenge key (therefore only allowing a login form to exist for x time period) and/or
- If the login screen is called again a new challenge key can be issued, therefore making all other login screens for that user to expire etc.

Another nice minor feature that I have encountered when using this pattern is that the users’ browser does not remember the password when they submit the form (even if the user is prompted by their browser). It is cleared from the password field before the form is parsed to the browser to process.

The new security patterns allows for a more secure entry point to the application and provides new strategies for logging in a user securely.

The technologies that have been used to implement were:
- MVC Architecture (Struts based, PHP port)
- RDBMS such as MySQL with ADO Database Abstraction (For tracking our challenges and our user accounts, could be extended to use a Directory Service if necessary)
- ACL (Access Control Lists, a good free one is phpGACL – PHP Generic Access Control Lists)
- PHP Hashing Algorithm (SHA 256bit, written by Feyd)
- JavaScript Hashing Algorithm (SHA 256 as well for the client side processing)

Note: The primary implementation calls for the use of client side JavaScript to allow the functionality of building the response string. If the client’s browser does not support JavaScript or has it disabled, then the password will still be sent in plain text through the HTTP Request headers. If you still wish to provide this backwards compatibility you can check to see if the password is submitted to the site and check as normal.

To achieve this pattern I created 2 database tables to contain the User and Challenge information. The User table contains login information, such as username and SHA hashed passwords, as well as ACL group and whether the account is active or suspended). By using a DB Table containing the Challenge information we can easily assign an expiry timestamp to the challenge and quickly locate issued challenges for particular sessions (handling garbage collection while we are at it).

The Action and ActionForm classes both control the user submission and the initialization of Controller variables for authorized state (e.g. issuing the challenge key, checking the form submission, checking the client submitted response versus the expected response and finally placing the user object in session). The user object contains information about the ACL Group and other required security information for the application framework as loaded from our User DB Table.

I have extended the checks of the Request Processor to identify the state of the user (if they are logged in they are a member of an ACL group and can be validated against an action path check, otherwise they are provided the default ACL group of public which allows them to call public selected actions, such as login and reset password actions which are granted to all groups and the public). If they do not pass the ACL check they are then referred to a “request-error.html” explaining the possible causes for their denial.

Therefore all actions in our application are centralized through security checked with ACL (before any process actions are created or called).

In my User class I have also implemented the method touch() and isActive() with a variable timestamp and timeout period in seconds - allowing me to have more fine grain control over the users session activity. Using the method isActive checks to see whether the users activity period has not timed out, and touch() causes our timer to restart. I can then have control from the server over session timeouts and can handle them accordingly. I have also incorporated this into my Request Processor to gain better control once the user has logged in.

The User object can be sourced from the application framework to check for the timeout length and notifications in the view could be created to notify the user when their session is about to expire (such as using an alert). The timeout length can also be dynamically adjusted if for the sake of over-engineering.

Note: If the user is still performing an action the alert could prompt the user to re-login their user into the session in a separate popup window (refill in their username and password). This would then allow them to continue their action in the original window, without risk of submitting to an expired session (loosing their form submission).

Overall the pattern provides the application with a significant upgrade to the intelligence and security of User authentication. Passwords are not sent in plain text and the password can not be intercepted on a network and are upgraded to 256bit encryption. By extending this pattern using ACL lists for action path checks the authentication process is maintained in a database opposed to the source code, meaning unlimited groups can be created granting on use of certain actions in your MVC application. You introduce the ability of expiring screens in your application and have further control on stomping out “Script Kiddies” and the like.

Always check out phpsec.org to ensure that the practices you take for implementing this pattern meet their recommendation. Remember to address basics with the application such as correctly treating user input (correctly quoting string input etc).