There are two basic models for establishing an e-Authentication system.
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.
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.
|Service provider establishes trust with the user directly.
|Service provider establishes trust with the broker who will perform authentication with the user.
|Direct Authentication works with most infrastructures.
|Brokered Authentication requires an infrastructure that supports the use of security assertion.
|Requires authentication for every connection to a different service.
|The same assertion could be used to access all services within an organisation.
|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.
Some examples of mitigation measures to complement the authentication process are provided below for general reference.
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 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:
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.
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 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.
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.
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
Various organisations have established channels and provided tools or guidelines to help with e-Authentication-related enquiries and issues.
OpenID is an open, decentralised and free framework for user-centric digital identity.
OpenSAML is an open source tool kit for implementing solutions with the use of SAML specifications. It is available for Java (1.4+) and C++ applications.
FIDO Alliance is dedicated to addressing the lack of interoperability among strong authentication technologies, and remedying the problems users faced with creating and remembering multiple user names and passwords.
The mission of the working group is to define a client-side API providing strong authentication functionality to web applications.