e-Authentication Models

There are two basic models for establishing an e-Authentication system.

Direct Authentication

When both the user and service provider participate in a trust relationship that allows them to exchange and validate credentials, direct authentication can be performed. Direct authentication requires the presentation of credentials from the user, which are typically a user name and password. The service provider uses these credentials to authenticate the request.

Brokered Authentication

In a situation where the user and the service provider do not share a direct trust relationship, a “broker” can be used to perform authentication. The broker authenticates the client and then issues a security assertion that the service can use to authenticate the user.

Below is a table showing the comparison between the two models.

Aspect	Direct Authentication	Brokered Authentication
Trust Relationship	Service provider establishes trust with the user directly.	Service provider establishes trust with the broker who will perform authentication with the user.
Infrastructure Support	Direct Authentication works with most infrastructures.	Brokered Authentication requires an infrastructure that supports the use of security assertion.
Cross-domain Access	Requires authentication for every connection to a different service.	The same assertion could be used to access all services within an organisation.
Usage Example	Direct user name and password authentication.	PKI-based Authentication which makes use of the verification service (i.e. OCSP) of the certification authority. Federation systems that depend on each other to authenticate their respective users and vouch for their access to services offered by other members of the federation.

Security Mitigations and Tips

Some examples of mitigation measures to complement the authentication process are provided below for general reference.

User Education

Relevant information should be provided to users. This would include increasing their knowledge of how to identify and mitigate risks. One example of user education is about how to check the name on the server certificate and how to check the “padlock” icon in the browser. Periodic education programme can help ensure users understand when and how to report compromise (or suspicion of compromise) or otherwise recognise patterns of behaviour that may signify an attacker attempting to compromise the token.

Server Certificates

Server certificates are the industry standard for authenticating servers. For example, the use of a server certificate can validate the server (by the client’s browser) before logging in a website. An additional benefit in using server certificate during user authentication is the encryption that can be provided. This means that the identity and password of the claimant will not be subject to interception in transit.

End User Control

Part of the difficulty in ensuring the integrity of an online transaction is the lack of end user control. This ranges from varying degrees of clients’ technical knowledge to different browser configurations and operating systems. Options for gaining some control or consistency at the client end include the use of:

Special hardware devices; or

Software installed at the client end capable of encapsulating technology solutions for authentication, without reliance on the client to operate complex procedures.

Physical Security

This option is applicable to most internal online transactions, where the end-user workstation is located at the physical premises of the organisation. However, it is less likely to be available for Internet-based applications. The viability of this option depends on the location and the provision of a suitable network.

Mutual Authentication

This involves the service provider authenticating itself to the client by providing information only known to the service provider and the client at the time of transaction. The purpose is to mitigate the risk of phishing in which the service provider will show the client information that fraudulent websites would not have access to. There are many variants with this option but each should include displaying to the client information that only the service provider and client would know. Examples include:

The last transaction date and time;

A pre-determined shared secret;

Displaying a pre-selected graphic; or

Displaying the full name and address of the client as a greeting.

The use of a server certificate can also validate the hosting server (by the client’s browser) before logging in the service provider’s website. An additional benefit in using server certificate during user authentication is the encryption that can be provided, so that the credentials of the user will be protected from interception in transit.

“Out of band” Considerations

An “out of band” solution may be an option for high-risk transactions or as an alternative to a purely technical solution. This solution usually involves certain communication or transmission between the client and the service provider, which is not reliant solely on the Internet for transmission. Examples of “out of band” solutions include mobile phones, SMS messaging, telephone calls or service mails. An “out of band” solution involves a higher level of complexity and infrastructure that would have to be balanced against cost and benefits being obtained.

Transaction Agreements

Set up transaction agreements to protect against unauthorised access to services or financial transactions. Any transactions made outside certain limits or times would trigger an exception process where the transaction may be delayed until off-line verification can be obtained from the client. Examples of these would be immediate acceptance of transactions during office hours on certain days of the week, and the automatic delay of transaction made outside these agreed times until off-line verification can be obtained.

Programming Techniques

One technique used by hackers to implement fake websites is using the legitimate website as a background and superimposing the fake site across the top of the legitimate website. From the client perspective, the website looks real, acts appropriately and contains the legitimate TLS padlock. The client is then prompted to enter their details into the fake site where the hacker obtains their authentication details. Some programming languages (e.g. JavaScript) have functions available to detect if the section of the website is embedded in a frame, and if so to push the legitimate section of the website to the front. This should be able to prevent hackers from superimposing fake website sections over the top of legitimate ones.

Handling of Unsuccessful Log-in Attempts

Proper handling of unsuccessful log-in attempts would help lower the risk of attacks through password guessing. Some common practices include temporary suspension of user account or access right, and a longer waiting time before the user is allowed to retry, upon a predefined number of unsuccessful log-in attempts.

Transaction Records and Account Activity Monitoring

The client should be provided with regular and detailed transaction records to allow them to identify fraudulent activities. Periodic checking of account activities should also be undertaken to identify exceptional behaviour that may indicate fraudulent activities on a user account, for example, excessive transaction requests within a short period or excessive service requests compared to previous behaviour.h3

Technical Resources

Various organisations have established channels and provided tools or guidelines to help with e-Authentication-related enquiries and issues.

Language