Hi,
I hope those that had a holiday or time with those people close to you had a great time.
As others have said, Authentication systems typically have a fair bit of complexity surrounding them. It is also true that when developers custom role their own security system they experience the depths of these complexities and security concerns. We want to end with a set of authentication and permission classes that ‘hide’ this complexity from the end user and provide great documentation so a junior user can understand how to safely implement these classes.
Even if we start with some bad code, I am confident that we can refactor it so that it becomes simpler and better.
As @YuriKolovsky; raised the questions regarding requirements&p=5097968&viewfull=1#post5097968) we can use this as a start to discussing and refining the requirements we wish to serve.
The system should have a users database with the corresponding users with hashed passwords, user details, and permissions set in one to many relationship user to permissions. For flexibility we could also look at implementing a similar structure in flat files /XML/YAML… that could be parsed into objects that ‘act’ as a database?
Yup cryptography is tricky and hashes do keep getting reversed. This means that our system can’t ‘hard’ code hashing, we need to be able to hash the users details using a supplied hashing algorithm that can be loaded into our system. When hashes do get cracked/reversed then a developer can supply a safe hash.
Multi application and across servers should be possible with appropriate SESSION handling and keeping the database separate from an application.
- Authentication logic does to execute in the form. If a hacker tries to spoof the form we don’t want them to bypass the authentication logic.
- We bind input parameters into the database and all form, SESSION, GET, parsed file logic should be filtered for special characters
- We will regenerate the SESSION id everytime an important user function is launched. We also will use a token on login that will cause the session to regenerate.
- We will Mitigate CSRF by using Post on forms, require verification for sensitive actions, and using an anti-CSRF token.
- We will limit impersonation attempts by combining a SESSION and MD5 USER-AGENT
- For XSS we will, filter all input and escape output, use htmlentities() where appropriate, and allow only ‘safe content’,
- We will store the Sessions in the database (when using one) which will help with allowing it to run across multiple servers, and will help with performance on more demanding applications.
Initially my thinking was to use sessions with cookies and not support HTTP authentication.
Rather than building ‘Canned’ forms, it would be better to build a set of form examples that demonstrate how to integrate the classes, and validation into the form page.
Ultimately this would be a good idea.
[quote=“YuriKolovsky,post:16,topic:14056”]
Will there be javascript included and if there will, then how will the javascript be added to the html page? automatically or will the person have to add lengthy scripts and configure them too?
We have to be careful with Javascript as it can be turned off easily and in most cases hackers will be using a command line browser to attack. We should implement the JavaScript that provides convenience and a better user experience, however stripped away the authentication/permission management should be unaffected.
[QUOTE=YuriKolovsky;5097968]
How will the library be configured?
Probably not going too fancy with the structure and the deployment would make it easier to understand. All Auth classes would be under a single directory called ‘Auth’. Inside this directory their will be a ‘Scripts’ folder for any of the javascript.
Yes field server-side validation as well as AJAX field validation.
This is a nice feature that we would want I think?
I think that redirection is an important part of the authentication system so we will have a redirection class that is used inside our authentication system, however a user can make use of this redirector for any other redirect they need to implement.
My current Auth/Permission system does not have this but it is a great idea. We should include this in the feature set.
Yes users will belong to groups. Groups are mapped to permissions. Permissions designate roles and access.
We will define an initial set of permissions and groups, a user could make use of our permission mappings or they could create their own. The management of this would be provide using a number of PHP based pages that are designed to manage specific features of the authentication system.
If a user tries to access a restricted area without the appropriate permissions, they would be redirected somewhere without an error. In most cases the permissions are wrapped around the view logic in a way that things that are restricted to a logged in user are not seen; whereas someone with the appropriate permission will see those buttons, links, content areas and menus.
Yes, roles are defined as permissions; therefore roles can be thought of matching to groups of users.
I believe this should allow other third-party applications to provide validation of access. This get tricky though as quite a bit of thought has to go into how permissions will be granted or at least how users can be mapped so that they get the proper permissions?
Thank you YuriKolovsky for kick-starting this process!
Please feel free to add your thoughts to this high level description of some of the requirements.
Regards,
Steve
