Network Architecture for a Banking Web Application by rdy81758

VIEWS: 21 PAGES: 10

More Info
									WEB APPLICATION SECURITY IN UN-TRUSTED
CLIENT SCENARIOS
Author:                                   Mario Guido Finetti                             Date:                                May
2008
Version:                                  2.17




INTRODUCTION ............................................................................................................................... 2
  1. The client computer .................................................................................................................... 3
  2. The server-side architecture ........................................................................................................ 3
  3. The Internet connection .............................................................................................................. 3
  4. User’s authentication credentials ................................................................................................ 3
THE MOST COMMON AUTHENTICATION SOLUTIONS........................................................... 4
  User ID and password authentication .............................................................................................. 4
  One-time password generator tokens ............................................................................................... 5
  Crypto devices equipped with X.509 certificates ............................................................................ 5
SOLUTIONS NOT RELYING ON TRUSTED CLIENTS ................................................................ 6
  One-time Password Authentication ................................................................................................. 6
  USB token with cryptographic capabilities ..................................................................................... 7
  A solution not requiring any hardware authentication token ........................................................... 7
REFERENCES .................................................................................................................................... 9
INTRODUCTION
The strength of an authentication solution is generally classified depending on how many
“authentication factors” are checked when the user gets in touch with the computing system.
According to this classification, password-based authentication is relatively weak because the
authentication system only checks something you know, that is your password. Two- factor
authentication is better, because the authentication system checks something you have as well as
something you know, making sure that the user holds a hardware authentication token of some kind
in addition to the password. Three-factor authentication is the most secure solution because the
authentication systems checks biometric data in addition to your security token and some password
or PIN (“something you know, something you have and something you are ”).

Therefore, the typical IT professional’s advise is: “If you are not happy with your current
authentication solution, just add another authentication factor and it will be all right”.
Unfortunately, multiple factor authentication is not the solution to every authentication issue. On his
2005 blog post Bruce Schneier described this problem much better than I could do (the full article is
available at [SCHNEIER]):

       The problem with passwords is that they're too easy to lose control of. People give them to
       other people. People write them down, and other people read them. People send them in e-
       mail, and that e-mail is intercepted. People use them to log into remote servers, and their
       communications are eavesdropped on. They're also easy to guess. And once any of that
       happens, the password no longer works as an authentication token because you can't be
       sure who is typing that password in.

       Two-factor authentication mitigates this problem. If your password includes a number that
       changes every minute, or a unique reply to a random challenge, then it's harder for someone
       else to intercept. You can't write down the ever-changing part. An intercepted password
       won't be good the next time it's needed. And a two-factor password is harder to guess. Sure,
       someone can always give his password and token to his secretary, but no solution is
       foolproof. […]

       Attacker gets Trojan installed on user's computer. When user logs into his bank's Website,
       the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he
       wants.

Many authentication solutions exists to cope with un-trusted networks, to deal with users not
managing their credentials appropriately or to improve the credentials provisioning process, but
only few assume that client computers are un-trusted. This article gives an overview on the most
common authentication solutions and then explains how these solutions could be improved in order
to work in an un-trusted client scenario.

I will take, as an example, a Web application providing the typical home banking services,
including wire transfers. Some of the issues discussed here also apply to other scenarios like remote
management of production processes where not only money, but even human life could be at risk if
the computing system is compromised (see, as an example [NISCC]).

At a very high level, a home banking Web application is made of:
    1. a client computer with an Internet browser application;
    2. a server-side architecture;
   3. an Internet connection;
   4. user’s authentication credentials, including hardware authentication token if present.

Let us now analyze each component of this over simplified architecture.


1. The client computer

Home banking applications rely on user’s computer. The next section explains why all the most
popular authentication solutions require a certain degree of trust on the client computer.

Banks, generally, do not provide their customers with computers and, in any case, they are not
responsible for their management. The user is entirely responsible for the management of his
computer. As a consequence, you do not know if is managed properly (e.g. if the antivirus is up-to-
date, if the latest patches are installed, etc).

Also, some users may want to use the same computer for home banking as well as for applications
of any kind, coming from unknown sources. Virtualization technologies are increasingly being used
for meeting these requirements. A discussion on virtualization as well as client protection
technologies, anyway, is out of the scope of this article.

2. The server-side architecture

A discussion of the security issues of server-side architectures is by far out of the scope of this
article. For our oversimplified example, we can say that everything have been done in order to
protect the server-side architecture from external attacks and that the banks personnel is
trustworthy. Obviously, this is not always the case and, again, neither a good network protection nor
two- factor authentication are of any help if the server is not trusted.

A big difference between the server-side architecture and the client is that it is generally clear who
is responsible for server-side application management. Good management policies, therefore, can
be enforced.


3. The Internet connection

A lot have been written on the security issues associated with using unprotected network
connections. As a consequence, there is no home banking solution that trusts the network
connection between the client and the server. Using SSL/TLS and a PKI ensures the privacy of the
transmitted data, server authentication and, as an optional, client authentication. I would say this is
the less controversial aspect of a home banking Web application design.


4. User’s authentication credentials

Why should you trust user’s authentication credentials ? In other words, why should you believe
that the holder of a set of authentication credentials is the legitimate user of a computer system ?

Firstly, because you provided the legitimate user and only the legitimate user with the correct
credentials and you correctly linked the electronic identity of the user to the right real world person.
In other words, you can trust user’s credentials only if a secure identity management and credentials
provisioning process is in place.

Secondly, because you can reasonably assume that nobody took those credentials and used them in
order to impersonate the legitimate user. Here, the above mentioned classification of aut hentication
systems based on the number of authentication factors is helpful. Password based authentication, for
example, is relatively weak, because it is very easy to share passwords as well as to steal passwords
when they are written on a sheet of paper. As discussed in the next sections, trusting the
authentication credentials does not mean that you trust the communication channel between the
client and the server or the client computer itself. In other words, increasing the number of
authentication factors does not necessarily protect your system from the security issues related to a
compromised client computer or an unprotected communication channel. Biometric authentication
in a distributed environment is a good example: the most accurate fingerprint reader does not
necessarily grant a secure communication channel between the reader and the entity responsible for
verifying the biometric template [ISB].



THE MOST COMMON AUTHENTICATION SOLUTIONS
The most common authentication solutions for Web applications are:

   -   User ID and password authentication. In this case, it is often required an additional password
       for authorizing wire transfers.
   -   One-time password (OTP) generator tokens.
   -   Crypto devices like USB tokens or smart cards, equipped with X.509 certificates.

Other, less common, include:

   -   Randomly generated OTPs transmitted through a GSM SMS messages [SMSOTP]
   -   Personal information that only the legitimate user is supposed to know [OUTOFWALLET]

This section describes the first three authentication solutions and shows why they all rely on trusted
clients.


User ID and password authentication

The Web application requires a SSL/TLS communication channel. The user is asked to enter his
user ID and password in a HTML form. If the authentication is successful, user’s browser is given a
session ID in order to be recognized all during the application session, without being asked for
authentication at every mouse click.

Home banking applications do not generally rely on the session management mechanism for the
most critical operations like, for example, password change or wire transfers. The mentioned
operations require the authentication credentials to be typed and sent along with the details of the
requested operation. This prevents those highly critical operations to be performed by a malicious
user if the legitimate user leaves his computer unattended after logging into the Web application.

A part from user misbehaviors or implementation mistakes resulting in passwords or session IDs
disclosure (see, for example: [GUNTEROLLMANN] and [SESSIONFIXATION]), the biggest
security issue with this solution is that the client may not be a trusted environment. It is relatively
easy for a malicious user to steal the legitimate user’s password using a key logger tool installed on
the client computer.


One-time password generator tokens

The bank’s customer is provided with a hardware device, equipped with a LCD display and,
depending on how it is designed, a button. The OTP can be time-based or event-based. Time-based
OTPs are generated every 30-60 seconds while event-based OTPs are generated every time the user
hits the button. The end user is also provided with a PIN. The PIN and the OTP are both required
for logging into the bank’s Web site. The server responsible for OTP verification do not allow the
same OTP to be used twice, even during the 30-60 seconds validity period.

Time-based OTPs could be calculated as a hash of the current timestamp and a secret shared
between the token and the authentication server. Event-based OTPs could be calculated as a hash of
a counter and a secret shared between the token and the authentication server.

The plus of this solution are:
   - if the client is not trustworthy, the OTP token generator prevents the most simple kind of
       attacks (e.g. key loggers);
   - it does not require any additional software on the client computer;
   - it is two-factor authentication: the user needs the PIN in order to generate the first part of the
       pass code and the token to generate the second part of the pass code.

Unfortunately, a malicious user who gained a complete control over the c lient computer could take
advantage of the user log in and change the wire transfer amount or the wire transfer beneficiary
without changing the authentication data.


Crypto devices equipped with X.509 certificates

The bank’s customer is provided with a smart card or a USB token with cryptographic capabilities.
In this case, a PKI is required and the authentication is performed during the SSL/TLS handshake
phase. The private key of the user is entirely managed by the authentication token all during the
authentication process. A malicious user who even gained a complete control over the user’s
computer could not steal the private key and, therefore, reproduce the token.

The end user is also provided with a PIN, required by the client application and verified by the
token. I you lose the token, nobody will be able to impersonate you as soon as he does not know
your PIN. In addition, the USB crypto token is sometimes equipped with a fingerprint reader. In this
case, the token checks the biometric characteristics of the user before initiating a SSL/TLS
handshake.

As in the previously mentioned scenarios, if the client computer is not entirely trustworthy, a
malicious user could take advantage of a SSL/TLS session activated by a legitimate user for
performing illegitimate actions. This kind of issues are very well described in the RSA Laboratories
PKCS#11 specifications.

       Cryptography is only one element of security, and the token is only one component in a
       system. While the token itself may be secure, one must also consider the security of the
       operating system by which the application interfaces to it, especially since the PIN may be
       passed through the operating system. This can make it easy for a rogue application on the
       operating system to obtain the PIN; it is also possible that other devices monitoring
       communication lines to the cryptographic device can obtain the PIN. Rogue applications
       and devices may also change the commands sent to the cryptographic device to obtain
       services other than what the application requested [PKCS11].



SOLUTIONS NOT RELYING ON TRUSTED CLIENTS
This section gives an overview on how all the above mentioned solutions could be improved in
order to work in an un-trusted client scenario.


One-time Password Authentication

Let us suppose to provide the end- user with a one-time password token that looks like a calculator:
a small keypad and an LCD display.

Before authorizing any payment or wire transfer, the end-user is required to type in the device’s
keypad the beneficiary account number, the amount of money to be transferred and, possibly, a
PIN.

The device, then, generates a one-time password related to that information. The user is required to
enter the one-time password in a Web form in order to authorize the payment / wire transfer.

For example, the one-time password could be calculated as described below.

       OTP = hash( ALD + timestamp + k )

Where:
- hash()      is a secure one-way hash function, like for example SHA-1.
- k           is a key shared between the token and the server responsible for verifying the OTP
- ALD         (“Application Level Data”) is the string entered by the user in the device’s keypad
- +           means “concatenate strings”

A malicious user could not use this one-time password for any purpose other than authorizing the
operation requested by the legitimate user. As soon as the hardware equipment is trusted, the
payment process is secure, even if user’s client is entirely un-trusted.

A little drawback with this solution is that the user is required to type the beneficiary account
number and the amount of the wire transfer twice: first on the Web application and then on the
token’s keypad. In addition, the device itself cannot be very small because of the keypad. This
could result in an insecure user behavior like leaving the token on the computer’s desk, instead of
keeping it in the pocket.

For the best of my knowledge, VASCO is the only vendor of a solution of this kind. [VASCO]
USB token with cryptographic capabilities

Let us now suppose to provide our users with a USB token equipped with a LCD display and a
“OK” button.



                                                          “OK” button. The user clicks here if he
               USB port         LCD display               agrees to sign the message shown



                     MESSAGE TO BE SIGNED...              OK



The user could log into the Web application through a standard SSL/TLS handshake with client
authentication. After logging into the bank’s Web application the user is allowed to perform read-
only operations, like for example reading his account summary.

Before performing found transfers of any kind, the application is required to generate a simple
message containing the most relevant information about the operation being authorized. As an
example: “BENEFICIARY ACCOUNT NUMBER: 123456789; AUTHORIZED AMMOUNT:
100.00 USD; 10-11-2007 17:42:00; TRANSACTION#534”. The message is then
transferred to the USB token that will show it on the LCD display. The user is then asked to check
the message and press the “OK” button on the USB token if he agrees to authorize that operation. If
the user confirms the operation, the USB token electronically signs the message and gives it back to
the Web application.

As soon as the USB token is a trusted environment, the entire operation is secure, even if user’s
client computer is un-trusted. This solution is more flexible than the solution presented in the
previous section, because the signed data is not limited to what the user can type in a small numeric
keypad. In addition, this token is likely to be smaller and the user is not required to type the same
information twice.

Surprisingly, several security token vendors made a token with cryptographic capabilities, a LCD
display and a button available. Unfortunately, this kind of token can only work as a “hybrid token”:
a OTP generator for some applications and as a standard crypto token for other applications. Both
usage scenarios present the security issue described in the previous sections.


A solution not requiring any hardware authentication token

As we discussed in the previous section two- factor authentication, by itself, is ineffective if the
client computer is not a trusted environment. The vice- versa is also true: it could be possible to
design a one- factor authentication solution that remains secure in un-trusted client scenario. The
current section gives an example.

In this scenario, the bank should provide each user with a sheet of paper containing the table
described below.
Fig. 1: “Confirmation code” table
                   Last two figures of the beneficiary account number ( i )
            j i 00 01 02 03 … 10 11 12 … …… 99
           00      aij
           01
           02
           03
           04
         Transaction ID ( j )




           05
           06
           07
           08
           09
           10
           11
           12
           13
           14
           15


Where:
- i                                 the last two figures of the beneficiary account number;
- j                                 a server- generated transaction ID (from 0 to 15);
- aij                               the “confirmation code” required for each wire transfer.

Each element of the table (aij) could be calculated as a hash of the last two figures of the
beneficiary account number, the server generated transaction ID, the user ID and a secret kept on
the server responsible for verifying the code. In formulas:

aij = hash( i + j + userID + k )

Before performing found transfers of any kind, the Web application displays the recipient account
number along with the server-generated transaction ID. The end user is then asked to enter the
corresponding “confirmation code”.

Like in the previously discussed solutions, as soon as the table is kept confidential, the transaction
is safe, no matter how trusted the client computer is. In this case, a malicious user who gained a
complete control over the legitimate user’s client could only change the amount of money to be
transferred, without changing the recipient account number. In order to protect the amount of
money as well as the account number, we could think about providing the user with a second
“confirmation code” table (see Fig. 2).




Fig. 2: “Second confirmation code” table
                                                            Transferred amount ( i )
                                j      i “0-9.99” “10-49.99” “50-99.9” “100-199.99” “200-399.99” …
                              00   bij
                              01
                              02
                              03
                              04
       Transaction ID ( j )



                              05
                              06
                              07
                              08
                              09
                              10
                              11
                              12
                              13
                              14
                              15



In this hypothetic scenario, the end-user must be aware of the meaning of the “confirmation code”
tables. A malicious user who controls the client computer could always trick naïve users by asking
them to enter the wrong codes (e.g.: confirmation codes corresponding to a 200.000 USD operation
in favor of the malicious user’s account number). The so-called “fishing” attack, anyway, is a pretty
different kind of problem and it is out of the scope of an article focused on computer’s
vulnerabilities more than incorrect user behaviors.




REFERENCES
[SCHNEIER] Bruce Schneier, “The failure of two factor authentication”, March 2005,
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html

[NISCC] NISCC, “Good Practice Guide on Firewall Deployment for SCADA and Process Control
Networks”, February 2005, http://www.cpni.gov.uk/Docs/re-20050223-00157.pdf

[ISB] Bori Toth, “Biometric Liveness Detection”, Information Security Bulletin, Volume 10, Issue
8, October 2005, http://www.deloitte.com/dtt/cda/doc/content/ISB1008BT_final(1).pdf

[SMSOTP] Bruce Schneier, “Two-Factor Authentication with Cell Phones”, November 2004,
http://www.schneier.com/blog/archives/2004/11/twofactor_authe.html

[OUTOFWALLET] On out-of-wallet authentication: “Security: The Third Degree” by Benjamin
Sutherland, Newsweek International, 2007 Newsweek Inc. On the same topic, see:
http://www.newsweek.com/id/44152
[GUNTEROLLMANN] Gunter Ollmann, “Web Based Session Management. Best practices in
managing HTTP-based client sessions”,
http://www.technicalinfo.net/papers/WebBasedSessionManagement.html

[SESSIONFIXATION] Mitja Kolsek, “Session Fixation Vulnerability in Web-based Applications”,
December 2002, ACROSS Security, http://www.acros.si/papers/session_fixation.pdf

[PKCS11] RSA Laboratories, “PKCS #11 v2.20: Cryptographic Token Interface Standard ”, June
2004, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

[VASCO] VASCO Data Security International. Company’s Web site: http://www.vasco.com

								
To top