25th April 2006
Amended 1st May 2014
Compliance with various security requirements is essential if an application is to be taken seriously by prospective clients. Having no security at all can lead to delicate information falling into the wrong hands, or allowing delicate information to be modified or destroyed by unauthorised personnel. On the other hand, too much security can prevent an authorised person from completing a legitimate task. Clearly some sort of balance is necessary, and each decision, whether to employ or not employ a particular security mechanism, may benefit from explanation and justification.
The purpose of this document is to identify what security features either do or do not exist within RADICORE, and to give explanations where necessary. It should be noted that RADICORE is a web application that uses the stateless HTTP protocol, which means that certain options which are available to traditional desktop applications are inapplicable.
The RADICORE system forces every user to navigate through a login screen which requires the input of a user_id and a password. These will be validated against the contents of the USER database table, and only if there is a match will the user be allowed to proceed. If either of these inputs is wrong a simple "security violation" message will be issued which does not identify which of the inputs was wrong.
Internal password authentication may be replaced with external authentication by using either a RADIUS or an LDAP server. These servers may allow passwords to be either static or supplied by a One Time Password (OTP) generator in order to implement Two Factor Authentication (2FA), also known as Two Token Authentication (TTA). This password generator, which may be either a piece of hardware or software, will generate random passwords which can be used only once.
A user's login rights can also be restricted to a particular date range by means of a START_DATE and END_DATE on the user's profile. If the user attempts to login outside of this period then a suitable error message will be issued.
There is also provision for a user's login rights to be temporarily disabled by an administrator by setting an IS_DISABLED flag on the user's profile. All rights can be restored simply by unsetting this flag.
RADICORE provides the following methods for logging out:
Note 1: It is not possible to return the client to the logon screen until the client issues a request as the web server cannot initiate any activity on the client, it can only send a response in reply to a request from the client.
Note 2: It is not possible to force the client to send a "logout" request to the server. The client may terminate the web browser at any time without sending any notification to the server.
Note 3: It is not possible to prompt the user to save any pending changes as the web application is totally unaware of any activity on the client until the client issues a request.
It may be a requirement in some systems to ensure that the same user is not logged in from multiple locations, and for a second login to automatically cancel an earlier session, but that is not implemented in RADICORE. Special facilities have been built into RADICORE to allow a user to open multiple sessions on the same client as this is a legitimate method of working. It is only possible to limit these multiple sessions to the same device provided that the device has a static IP address. See Restrict access to authorised devices for details.
It may be a requirement in some systems to ensure that the system does not crash because of too many users, but that is not practical in a web application:
It may be a requirement in some systems to record the start time, end time and duration of each user session, but as a session can end without the server receiving a "logout" request this is not completely practicable. However, all login attempts, whether successful or unsuccessful, are logged, and all logout requests, when received, are also logged.
Although RADICORE forces each user to have a unique identity, it does not force each user to have a unique password. This is because each user password is encrypted with a different key, which means that it would not be possible to perform a lookup on a particular password without first decrypting all the existing passwords. Besides, what benefit comes from having unique passwords? A password on its own is nothing, it is only the combination of user_id and password that has any significance, and not every password is valid with every user_id.
When changing their passwords, users must retype them in order to confirm them in order to avoid spelling mistakes or typing errors which would render their passwords as ineffective. Any mismatches must be cleared before a password change can be put into effect.
The system must allow passwords to contain both letters and numbers, and to distinguish between upper case and lower case.
RADICORE allows the system administrator to define a valid format for new passwords by means of the following specifications:
These alphanumeric characters can appear in any order as it is only their number which is checked.
These formatting rules are enforced only when passwords are being changed, not when being entered in the login screen.
It must be possible for a system administrator to define a minimum length for new passwords. This can be anywhere between 1 character and the maximum size (currently 16 characters). This rule is enforced only when passwords are being changed, not when being entered in the login screen.
To help protect against denial of service attacks the system must have some sort of lock-out mechanism after a predefined number of failed login attempts. RADICORE has the following features:
The system must ensure that all passwords are encrypted before being stored in the database. Also, when comparing passwords the system must encrypt the input password instead of decrypting the actual password so that a plain-text version of the password is never passed over the network.
It may be a requirement in some systems to use one-way (i.e. non-reversible) password encryption in the belief that this is more secure, but this is a false assumption. It is possible for a determined attacker to break any encryption algorithm, one-way or not, so the only defence is to use an algorithm which requires so many resources to break that it is not worth the effort.
The algorithm employed within RADICORE is reversible, but the encryption process requires a separate customisable key. Even if an attacker knew the algorithm he would have to know the key that was used during the encryption process in order to decrypt it.
The encryption algorithm employed within RADICORE does not use simple character substitution but progressive substitution, which means that if the same character appears more than once in the input string its encrypted equivalent in the output string will not be the same.
Having a reversible (two-way) encryption process does mean that the settings (algorithm or key) can be changed at any time without losing the current password values as known by the users. Simply decrypt all passwords, change the settings, then encrypt all the passwords again using the new settings.
The system must ensure that the password that a user types into the login screen is encrypted before being transmitted over the network. This will ensure that an eavesdropper does not have access to a plain text version of any password.
RADICORE achieves this by ensuring that each screen which requires the user to enter a password is transmitted using SSL (Secure Socket Layer) via the HTTPS protocol. This can be verified by seeing the characters
HTTPS:// at the start of the URL, not the unsecure
If a user forgets his/her password then there should be a method of retrieving it without requiring the intervention of an administrator.
RADICORE achieves this by supplying a "recover password" link on the login screen which will activate a form into which the user can enter his/her e-mail address. This address is used to locate the user's details in the MENU database, then the password is e-mailed to this address. The user can retrieve this message from his/her e-mail inbox and use the details to gain access to the system.
The system must allow the user to change his/her password at any time.
RADICORE achieves this in the following ways:
The system must allow the system administrator to define an interval after which the password must be changed.
RADICORE achieves this in the following ways:
It may be a requirement in some systems to remember a selected number of previous passwords for each user so that a new password for the same user is not on this list, but this facility is not available in RADICORE. Currently the only check is that the proposed password is not the same as the existing password.
It may be a requirement in some systems to check proposed passwords against a list of reserved words so that common words, or words which may be easy to guess, are not used.
RADICORE does not do this as the Formatting Rules give the system administrator the ability to define patterns which automatically eliminate common words.
User accounts can only be de-activated by a system administrator.
In RADICORE the ability to de-activate or modify user accounts is by default given only to system administrators. There are two ways in which an account can be de-activated:
Whichever method is chosen will, of course, be recorded in the system's audit log, as will any failed logon attempts.
The system has to ensure that it will be possible for customers to decide whether they want to enable/disable the auto-complete feature for user names and passwords.
This is an optional feature of the web browser and cannot be modified by the application software which runs on the server.
RADICORE does not have an auto-logon facility, therefore everyone must go though the login screen.
A system may have hundreds of users and hundreds of functions, but not all users may be allowed to access all functions. The system must therefore have some method by which a user's access to functions can be defined and limited, and all access attempts must be verified against this list.
RADICORE achieves this by having all information regarding functions, users and access control maintained in a central database. The functions to maintain the contents of this database are, by default, only accessible by a system administrator. The structure of this database is as follows:
RADICORE also employs a dynamic menu system in which all menu pages are maintained within the database. When a user selects a menu the details are retrieved from the database and compared against the ROLE-TASK table so that any functions which are not accessible by the user are automatically filtered out before the menu options are displayed.
This method therefore has two levels of functionality:
The system should also handle access control at the field level. Normally all fields are available, but there should be a facility to make certain fields either read-only or hidden for USERs of certain ROLEs.
RADICORE achieves this by allowing an administrator to define the following on the central database:
Note: This facility is not provided by any mechanism within the database as everyone shares the same database login, without which the pooling of persistent connections would not be possible. It is instead provided completely within the application. This is made easier by the fact that each HTML page is built completely from scratch each time rather than being taken from some pre-compiled definition. When building the page easy it is therefore a straightforward process to make any HTML control read-only instead of writable, or not to include it in the output at all.
It possible for the same database table(s) to hold data for several different customer accounts, but where users within an account can only access records (rows) which belong to that account. Account access can be turned on for any database table simply by adding a column called
rdcaccount_id. The features of the RADICORE implementation are:
rdcaccount_idcolumn has the value '1', or the table does not contain the
rdcaccount_idcolumn are shared, not private, therefore can be viewed and modified by users within any account.
rdcaccount_idcolumn may have a mixture of shared and private data:
rdcaccount_idcan only access shared data.
rdcaccount_idcan only access data which belongs to that account, plus any shared data.
This topic is discussed in greater detail in Implementing Virtual Private Databases.
The system must have control mechanisms that prevent the accessing of functions outside the predefined access path, based on the access rights given to users. Unauthorised users must not be able to access, change or otherwise corrupt the data within the system.
RADICORE deals with this in the following ways:
The system must have provision for granting automatic access to every function within the system without having to rebuild the access control list. This facility is required for system administrators, not everyday users.
RADICORE achieves this by having a GLOBAL_ACCESS switch on the ROLE record. If this switch is turned ON then all users with this role have global access. If this switch is turned OFF then access to each function is disabled until it is specifically enabled.
It may be required to restrict system access to authorised client devices. The following options may be required:
With web applications each client device is recognised by its IP address. RADICORE implements this feature by maintaining a list of valid IP addresses for each user and each task. By default these lists are empty and this feature is turned off, but it may be turned on at any time by creating a non-empty list. Any number of IP address entries can be specified for each user and each task.
User access is checked when passing through the logon screen. Task access is checked whenever a task is requested, either through a menu button or a navigation button.
NOTE: This feature is only applicable to those devices which have static (fixed) addresses. In situations where IP addresses are assigned dynamically, such as through a DCHP server, or where they are shared or masked, such as through a proxy server, this feature will not work as expected.
It may be required to restrict system access to authorised time periods, either for individual users or all users within specified roles. It may be a requirement, for example, that a user can only access the system during normal office hours (such as 9am to 5pm, Monday to Friday), so access outside of these hours can be blocked.
Time limited access is checked at the start of each task. If there are time periods in force, and the current time is not within any of those periods, then the user will be logged off. The user will be given a warning when within 5 minutes of the period end.
Data recorded in the Audit database may never be deleted or overwritten by anybody.
The RADICORE framework has facilities to write entries to the Audit database, and to view Audit records using a standard set of online screens, but there are no facilities which allow the user to modify or delete any entries.
This security requirement may be further enhanced by making use of MySQL's ARCHIVE storage engine which has two significant features:
The system must have the capability of logging changes to all database tables, and there should also be a standard set of screens to search through and view the contents of the audit data.
The RADICORE framework comes with a ready-made AUDIT database, functions to write to the database and functions to search through and view the contents of the database. All the system administrator has to do to enable the logging of changes to any database table is to visit the Update Table screen in the Data Dictionary and turn on the "Audit Logging" switch, then export the details so that they can be used by the application.
When audit logging has been turned on for any database table this will by default include every column in that table. The logging of a particular column can be turned off by visiting the Update Column screen in the Data Dictionary and switching the "No Audit" flag to YES, then export the details so that they can be used by the application.
The following details are written to the AUDIT database and are viewable using the online screen enquiry:
Th AUDIT database used within RADICORE has a fixed structure which can deal with deal with any number of application tables. This has the following advantages:
The system has to ensure that if there is an error during a user session that details of the error are automatically captured and made available to the system administrator. This removes the responsibility from the user who may not be aware of the procedure for reporting such incidents, or may not provide enough information.
In the RADICORE framework this is achieved by passing all errors through a standard error handler which performs the following:
errorlog.htmlwhich can be viewed through any browser.
© Tony Marston
25th April 2006
|01 May 2014||Amended section 3.1 Role Based Access Control - Function Level to allow a User to belong to more than one Role.|
|22 Jun 2013||Added section 3.7 Restrict access to authorised time periods|
|01 Dec 2009||Added section 3.6 Restrict access to authorised devices|
|01 Oct 2008||Amended section 1.1 to include the option of additional authentication via an LDAP server|
|01 Feb 2008||Amended section 1.1 to include the option of additional authentication via a RADIUS server|
|01 Oct 2007||Added Row Level Security (RLS)|