Mutual authentication protocol for HTTP

Research Overview

Background

In the Internet, "phishing", which ropes users in a fake Web servers of famous companies like brand shops and make them input their personal data and get them by fraud like password, credit card number and so on, is a very serious social problem. In 2007, Anti-Phishing Working Group (APWG) reported that 90% of phishing messages were from fake financial institutions and 250,000 phishing site were alerted only in one month (December 2007.) In 2007 report by National Public Safety Commission Japan, among 1,438 arrested unauthorized access crimes, 1,157 were to cheat passwords by phishing and most of all passwords were for internet auction sites.

When a user inputs his/her personal data, confirming that the server address is the one to which the user want to communicate in the address bar of the Web browser is fundamental to prevent phishing. But it is very difficult even for experienced users to confirm that every time or in the case that the domain name of a phishing server is confusable.

Recently, major Web browsers bundle anti-phishing features which warn the user not to communicate any more by showing a warning message like "This server might be a phishing server." when the user connected to the phishing server and if the server is black-listed. This countermeasure is effective only in cases that roping users in the phishing server indiscriminately like spam e-mails, not in cases that the users are targeted because the phishing server might not reported in time and the alert might be too late in those cases.

For those reasons, financial institutions start to adopt two-factor authentication methods like password with one-time token systems, but it is pointed out that two-factor authentication methods are vulnerable to some kinds of man-in-the-middle attacks which relay the user's messages to the real server and server's messages to the user. Actually, a real phishing for bank accounts using this attack was reported in 2006.

Details

We developed new "HTTP Mutual Access Authentication Protocol" to overcome phishing threats. This protocol introduces a new cryptographically-secure method to authenticate users against servers, and also servers against users, only using users' passwords. By introducing true mutual authentication, phishers become impossible to establish successful authentication anymore. We have implemented a Firefox-based Web browser and Apache extensions for this protocol.

Figure 1: MutualTestFox, the browser implementing HTTP Mutual Access Authentication. It is easy to check the validity of the server by confirming the green user ID field.
Figure 1: MutualTestFox, the browser implementing HTTP Mutual Access Authentication. It is easy to check the validity of the server by confirming the green user ID field.

This authentication protocol is effective to prevent phishing attacks in the following way:

  1. Passwords are input to the dedicated password field for HTTP Mutual Access Authentication in the address bar of Web browsers implementing the new protocol. (See Figure 2)
  2. Passwords input to the dedicated field are transformed into authentication data, not as it is, in some cryptographic way, and sent to the server, because this protocol uses PAKE (Password Authenticated Key Exchange) as a basis. Therefore, even if a user input his/her password to the field when he/she is connecting to a phishing server, the phishing server cannot get knowledge of the input password.
  3. In this protocol, not only the server can authenticate the user, but also the user can authenticate the server by checking that the server knows some knowledge of the user's password which means that the server is the one on which the user was registered in advance. This property unable the phishing server to camouflage as the real server because the phishing server does not know the user's password.
  4. During logging in, user ID is indicated in the dedicated field, and its background is green, in the address bar of the Web browser in HTTP Mutual Access Authentication protocol. (See Figure 3)
  5. Man-in-the-middle attacks which relay the user's messages to the real server and server's messages to the user are impossible because the domain name of the connecting server is also used as input and it must be the real server to be authenticated by the user.
Figure 2: HTTP Mutual Access Authentication is required.
Figure 2: HTTP Mutual Access Authentication is required.
Figure 3: Login state of HTTP Mutual Access Authentication displayed.
Figure 3: Login state of HTTP Mutual Access Authentication displayed.

In form-based authentication, the password input field is in the content area of a Web browser. So if a user inputs his/her password when he/she is connecting to phishing site, the password will be easily stolen. In Basic Access Authentication or Digest Access Authentication, user ID and password fields appear in a pop-up dialog window. In those cases, the fake pop-up dialog windows which are pictures in the content area of the browsers are very difficult to distinguish from the real ones.

On the other hand, the address bar area is secured not to be rewritten by Web contents in standard Web browsers now. If the password input field is within this address bar area, it is impossible to fake the field. Since the input passwords are transformed to authentication data from which the phishing server cannot get knowledge of the passwords by the browser and sent to the server, users can input their passwords into the dedicated field safely.

Since a browser authenticates a server in HTTP Mutual Access Authentication, if login is successful, the server is the real intended one. The only thing to do for a user is to confirm that he/she is logging in by checking that user ID is indicated in the dedicated field within the address bar and its background is green. If it is, the user can accredit that contents in the web page are of his/her intended server.

Consequently, in the future that this authentication method is widely prevalent, phishing will not be possible if a user behaves in the following way:

  • A user must input his/her password only to the dedicated password input field within the address bar.
  • A user must input personal data like credit card number into the content area only after he/she confirm that he/she is logging in for HTTP Mutual Access Authentication. (See Figure 3)