AU2007101199A4 - Method of adding two-factor authentication support to a username and password authentication system - Google Patents

Description

00 O DESCRIPTION The most common authentication system currently in use today for online services relies on the use of a username and password to authenticate oo a client to the computer server. This form of authentication is cheap and easy for an online service provider to implement, and is reasonably convenient for a client to use, but it has a number of well-known security problems.

To improve the security of client authentication, many organisations that provide online services are upgrading existing username and password authentication systems to support more secure forms of authentication, particularly two-factor authentication.

Two-factor authentication systems typically require the client to use a hardware device (something that they have) in addition to a secret password (something that they know) to authenticate. Such systems include the use of One-Time-Password (OTP) tokens, smart cards, USB cryptographic hardware tokens, and Transaction Authentication Number (TAN) sheets.

There are several issues with upgrading an existing username and password system to support two-factor authentication. These include: the integration costs of adding support for two-factor authentication processes, which can be expensive because integration often involves substantial customisation of the legacy system and must usually be performed in a way that maintains service availability, and the costs of personalising two-factor authentication tokens for use by clients and delivering these to clients in a secure manner.

The invention provides a way of upgrading an existing username and password authentication system to add support for two-factor authentication of clients, with little or no change required to the existing system and without having to customise authentication devices prior to delivery to clients.

The invention works by having a security proxy server component (referred to as the Security Proxy) manage the security processes associated with authentication of the client's hardware authentication token. The processes associated with authentication of the client's password are not managed by the Security Proxy, but instead continue to be managed by the so existing username and password system.

This approach is unique from other implementations of two-factor Oauthentication, which typically combine the processes of authenticating the oclient's token and the client's password into the one system, often in a way that requires substantial modification of the legacy system. Separating out oo00 55 these processes provides two major benefits.

The first major benefit of the invention is that little or no change is required to the legacy username and password system. The Security Proxy is simply added to the legacy system to authenticate a client's token. After the Stoken has been authenticated, the Security Proxy then retrieves the client's 60 username from a local data store based on a token identifier, and forwards the Susername and password credentials to the legacy system for processing.

This completes the authentication process and provides the client with access to the online service.

The second major benefit of the invention is that, by utilising the existing username and password authentication system, the client's token does not need to be customised prior to delivery to the client. The initial use of the token by the client will instead prompt the client to enter their existing username and password credentials, as for conventional access to the online service. If these are found to be correct, then the token used by the client is registered by the Security Proxy as belonging to the client. All future access to the online service by that client will then only require the client to use their token and enter their password, since the Security Proxy will retrieve the username invisibly for them, based on identification of the token, and will forward this username along with the password to the legacy system for access to the online services.

To describe how the invention works in more detail, and to define terms, we first describe the generic processes involved in a conventional username and password authentication system.

Referring now to Figure 1, which depicts a simplified network diagram of a conventional username and password authentication system, the generic process involves authenticating a Client 10 to a Security Server 51, so that the Client can be allowed to access Online Services 53. The Security Server and the Online Services are often hosted by the same organisation, which we refer to as the Service Provider 85 The authentication process involves the Client Computer 31 sending Sthe details of the Client's username and password, otherwise known as the oClient credentials, across the Internet 70, for verification by the Security Server 51. The Security Server verifies the Client credentials using a oo00 Customer Database 52 of known usernames and passwords (or derivatives of the password, such as the password cryptographic hash value), and allows or denies access to the Online Services 53 based on whether the credentials are correct.

The details of how information flows between the Client Computer 31 and the Security Server 51 depends heavily on the computer protocols S 95 employed, and is not relevant to the invention. It is noted, however, that additional security processes are often in place that are separate to the username and password authentication process just described. For example, Web-based services often involve the Security Server 51 authenticating to the Client Computer 31 using the Secure Sockets Layer (SSL) computer protocol.

o100 This involves the Security Server using asymmetric cryptography to prove its identity to the Client Computer and to establish a Secure Session 71 between the Client Computer and the Security Server. This Secure Session is then used to encrypt any future data transported during the session, including the Client username and password details.

105 Turning now to Figure 2 to describe the invention, which shows a simplified network diagram, the invention consists of a new component, called the Security Proxy 40, which is used to manage the processes associated with authentication of the Token The Security Proxy component may operate in one of two possible 110 ways. The first way is that it may be configured on the network to proxy all authentication traffic between the Client Computer 31 and the Security Server 51, including username and password authentication traffic and two-factor authentication traffic. The second way is that it may be configured to only proxy two-factor authentication traffic, with the username and password 115 authentication traffic travelling directly between the Client Computer 31 and the Security Server 51, without involving the Proxy Server 41. The invention covers both possibilities.

To provide a detailed description of the first possible way for the Oinvention to work, we describe the use case scenario where a Client 120 accesses the Online Services 53, with or without a Token 20, where the network has been configured to route all authentication traffic from the Client oo00 Computer to go via the Proxy Server 41.

The authentication process starts when the Client attempts to connect to the Online Services 53. This could be by the Client inserting their Token 125 into their computer, as per Australian Patent #2006100953, or it could be via some other means, such as by using conventional Web browser or Virtual Private Network (VPN) client software to access services with or without a SToken.

The request to access the Online Services is routed to the Proxy 130 Server 41. The Proxy Server then sends a request to the Client Computer for cryptographic client authentication as part of the security protocol handshake.

This could be achieved, for example, by establishing an SSL session with the Client Computer and requesting SSL client authentication during the initial SSL security handshake.

135 The Client Computer next handles the request for Client authentication.

If a Token is present, then the Client Computer may respond to the request for Client authentication using cryptographic key material that is retrieved from the Token. If a Token is not present, then the Client Computer would respond to the Proxy Server without providing the necessary information for Client 140 authentication, or would use key material that was not retrieved from a Token.

If the Client authentication response is provided, then the Proxy Server 41 checks this information to successfully authenticate the Token 20. This check includes a check on the cryptographic key material that was used to generate the Client authentication response. Specifically, the Proxy Server 145 confirms that the key material used by the Client must have been retrieved from a known type of Token, because for example the public keys used in the response are known to have been signed by a Certification Authority (CA) that only signs public keys that have their corresponding private keys stored on these Tokens.

150 If the Client authentication response is not provided, or is not generated using a suitable Token, then the Security Proxy may decide to allow or deny the Client Computer access to the Security Server for username and Opassword authentication, based on the configured security policy.

oAs part of the process of authenticating the Token 20, the Proxy Server 155 41 may use information from a Token Database 42 to see if the Token is oo00 known and/or if it has previously been used. If it has been used, then the Proxy Server may retrieve information about the Client from the Token Database, such as their username.

Following the initial authentication of the Token 20 (when present), the 160 Proxy Server 41 forwards the request to access the Online Services 53 to the r- Security Server 51. The Security Server may respond to the Proxy Server Swith a request for login credentials.

The Proxy Server may forward this request for login credentials to the Client Computer in its original form, or alternatively if the Client has already 165 been identified by the Token and the Token Database, it may change the request so that only a password needs to be provided (instead of a username and a password).

The Client Computer responds to the request for login credentials by providing the Client's password, and possibly also the username. This 170 information is sent to the Proxy Server. The Proxy Server then forwards the password and the username, which is either sent by the Client Computer or is retrieved from the Token Database, to the Security Server.

The Security Server finally authenticates the Client using the username and password credentials, using the same mechanisms that are used for 175 regular username and password access, and provides the Client with access to the Online Services.

To provide a detailed description of the second possible way for the invention to work, we now describe the use case scenario where a Client accesses the Online Services 53, with a Token 20, where the network has 180 been configured to only route authentication traffic between the Client Computer 31 and the Security Server 51 that involves the use of a Token.

A preferred way to implement this is using Australian Patent #2006100953, where the Client Computer 31 will automatically connect to the Proxy Server 41 on insertion of the Token. Alternative mechanisms may also 185 be used, for example by providing the Client with a different login page to use when they are accessing the Online Services using a Token than when they Oare using username and password authentication.

oNote that, in this case, the processes involved where a Client accesses the Security Server for username and password authentication are 00 190 unchanged, and do not involve the use of the Security Proxy component.

The initial security handshake and authentication of the Token 20 by the Proxy Server 41, the retrieval of Client information from the Token Database 42, and the forwarding of requests between the Security Server 51 Sand the Client Computer 31 for username and password details proceeds 195 using the same mechanisms as described in the first way that the invention acan work.

Once the Client has been successfully authenticated by the Security Server 51, and if this is the first time that the Client has used their Token, then the Proxy Server 41 may be configured to change the Client's password that 200 is stored in the Customer Database 52. This could be achieved using existing mechanisms provided by the Security Server 51 for a Client to be able to change their own password, or it may require a minor update to the Security Server to provide this functionality in a secure manner to the Proxy Server.

Changing the Client's password may involve updating the password 205 value so that it is long and secure, and practically impossible to guess. Once this has occurred, the Token Database 42 can be used to store the original password value (which is still known and used by the Client) and the new password (which was set by the Proxy Server). Future access to the Online Services by the Client would then have the Proxy Server check that the 210 password value provided by the Client is correct, by comparing it against the old password value stored in the Token Database. The Proxy Server would then substitute this value with the updated, secure password value before forwarding it to the Security Server.

The benefit of this approach is that it effectively prevents the Client (or 215 anyone that may be masquerading as the Client) from being able to authenticate to the Security Server without the use of a Token, but at the same time it allows other selective Clients to access the Online Services without the use of a Token and without involving the Proxy Server.

This method may be used as a way of providing two-factor 0 220 authentication for Clients that request it or for Clients that perform high-value

(N

otransactions, without having to impact all Clients.

This completes the use case scenario description of the second 00 possible way that the invention can work. The remainder of this Section provides further information about the invention as a whole, and applies to 225 both ways that the invention can work.

_In a preferred form of the invention, the Tokens 20 used by the Client consist of conventional data storage media according to Australian Patent #2006100953. In this case, the Token includes a computer application, such Sas a customised Web browser or VPN client, which is executed by the Client 230 Computer. The configuration of the Token 20 and the Proxy Server 41 are consequently closely related. In particular, the Tokens would be configured to automatically connect to the Proxy Server, and would be configured to trust the cryptographic credentials of the Proxy Server. This avoids having to customise the Tokens for any specific Service Provider, because the Tokens 235 do not need to include any information about the Service Provider.

The Proxy Server may also be configured to provide secure access to multiple Online Services. When multiple Online Services are supported, the Proxy Server may determine the correct service to connect to based on information entered by the Client by displaying a list of possible services 240 and having the Client select one), or based on the Token used by the Client, or based on information from the Token Database, or based on a combination of these techniques.

The Proxy Server may also support different forms of authentication simultaneously. For example, it may allow Clients to access one Online 245 Service using username and password authentication only, but it may require the use of a specific type of Token for another Online Service, and another different type of Token for a third Online Service. The Proxy Server may also require that different Clients use different Token types for the same Online Service, for example based on information on what privileges the Client has 250 with the Online Service.

The Proxy Server may also apply security policies to determine the acceptable level of authentication for each Client. For example, the Proxy Server may be configured to only allow a Client to access an Online Service if Othey have not previously used a Token to access that service, or if they have 255 not been issued with a Token, or if they have not used the same Token at least three times to access that service.

oo00 The Proxy Server may also identify the type of Token used by the Client, based on the cryptographic credential that is provided during the security handshake, and may use this information when applying the security 260 policy to determine the acceptable level of authentication for each Client. The Proxy Server may optionally also forward this information to the Service Provider, so that the Service Provider can use this information to control the aprivileges that the Client has when using the Online Services.

The Proxy Server may also handle the periodic renewal of Token 265 cryptographic credentials. It may do this by automatically updating the cryptographic credentials on a Token after the Token has been successfully authenticated, or by recognising an existing Client that is using a new Token because their old Token is due to expire soon or has been marked as needing replacement, and assigning the new Token as belonging to the Client.

270 The invention described herein may be applied to any form of Online Service, including Web-based services and VPN services. The invention may also utilise any computer security protocol for authentication of the Token and the Proxy Server 41. A typical security protocol used for Web and VPN services, and one that would work well with the invention, is the Secure 275 Sockets Layer (SSL) protocol, however the invention is not limited to this protocol.

Claims (4)

1. A method of using a computer security proxy server (referred to as the Security Proxy 40 in Figure 2) with an existing online service that uses oo 280 username and password based authentication of clients, to add support for two-factor authentication of clients without having to substantially change the existing online service.

2. A method according to claim 1, where the Security Proxy provides services to authenticate the client's hardware authentication token, while 285 the existing username and password authentication system is used to check the client's password.

3. A method according to claim 1, where the Security Proxy supports the use of username and password authentication and two-factor authentication simultaneously for the same or different clients. 290

4. A method according to claim 1, where the Security Proxy registers a specific hardware authentication token as belonging to a client after the client uses the authentication token to access the online service and successfully authenticates using their username and password. The hardware token that is registered in this way may be the first token that 295 has been provided to the client or it may be a replacement token. A method according to claim 4, where the Security Proxy changes the client password to an automatically generated secure value that the client does not know after registering a hardware authentication token as belonging to a client. This is performed to prevent the client from being 300 able to access the online service in future without the hardware authentication token, and to increase the level of security inherent in the existing username and password system.