AIST > RCIS > News > 22 Apr 2008: Development of a Reference Implementation of Password-Based Mutual Authentication Protocol

22 Apr 2008: Development of a Reference Implementation of Password-Based Mutual Authentication Protocol

[10/JUL/2008 English summary published]

Summary:

Research Center for Information Security (RCIS, Director: Hideki Imai) of the National Institute of Advanced Industrial Science and Technology (AIST) (President: Hiroyuki Yoshikawa) and Yahoo Japan Corporation (Yahoo! Japan, President: Masahiro Inoue) have been collaborating to develop a new authentication protocol, "HTTP Mutual Access Authentication" which can prevent phishing in the Internet from January 2006. They released reference implementations of this protocol, a Web browser "MutualTestFox" and a module of Apache HTTP server "mod_auth_mutual" in RCIS Web site (https://www.rcis.aist.go.jp/special/MutualAuth/ ).

"MutualTestFox" is based on Firefox 3 source codes and developed by adding the functionality of "HTTP Mutual Access Authentication" to it, so MutualTestFox also can be used as a standard Web browser like Firefox 3. "mod_auth_mutual" is a module of Apache HTTP server which enable the server to communicate with a client in this new authentication protocol. Both are open-source software.

The aim of this release is to evaluate HTTP Mutual Access Authentication Protocol from the technical view point. They expect that the effectiveness of this authentication protocol is verified and some problems are pointed out by Web application developers, information security researchers and Web browser developers.

Figure1: MutualTestFox (HTTP Mutual Access Authentication available browser) (It is easy to check the validity of the server by confirming the green user ID field,)

Background

In the Internet, "phishing", which rope 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, creditcard 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 Commisssion 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 input 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 targetted because the phishing server might not reported in time and the alert might be too late in those cases.

For those reasons, finantial 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

"MutualTestFox" and "mod_auth_mutual" are implemented based on IETF Internet-Draft version 2 specifications. Not all features are implemented but enough features are available to verify the effectiveness of the new protocol to prevent phishing attacks.

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

Passwords must be input to the dedicated password field for HTTP Mutual Access Authentication in the address bar of the Web browser. (See Figure 2)
Passwords input to the dedicated field are transformed into authentication data, not as it is, in some cryptographical 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.
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.
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)
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 rrequied.

Figure 3: Login state of HTTP Mutual Access Authentication

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 passoword 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 cannnot 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 authenticate a server in HTTP Mutual Access Autentication, 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:

input his/her password only to the dedicated password input field whithin the address bar.
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)

Contact Information

Software Download Site: https://www.rcis.aist.go.jp/special/MutualAuth/

E-mail Addresses

　for Protocol (RCIS, AIST): mutual-auth-contact@m.aist.go.jp

　for Software (Lepidum Co., Ltd): mutualtestfox-contact@lepidum.co.jp