Good news: Chase responds to the study

Chase.com's site was one that was previously not using HTTPS for their login page - we in fact used them as an example in a video made in July to illustrate the issue at SOUP'08.

We are glad to note that now they are using HTTPS for at least their login page. Customers who visit http://www.chase.com are now redirected to https://www.chase.com/Chase.html. 

(Thanks to an alert reporter for notifying me to this.)

What banks can do and why that would help their customers

Currently, banks have a difficult time educating their customers about what is safe to do and what is not safe to do when attempting to interact with their bank. If banks do some simple things, it could help simplify the message to customers. Here are the policies that banks could use:

1. Use SSL to protect their entire site and deliver all content. EV SSL certificates may be even better. See the following article: http://www.digicert.com/extended-validation-ssl.htm 
2. Use a single domain for all parts of the site that you are asking users to trust or interact with. For example, the login credentials should be on a page that clearly belongs to the bank. (Note: It is possible to do so while working with an external service provider by proper use of SSL certificates.)

Once most banks do that, the message to educate the customer becomes very simple. Here is the message to customers:

1. Customer should ALWAYS check that the URL for their bank starts with HTTPS. Otherwise, assume it is NOT from the bank.
2. Customer should always check the hostname in the URL is the bank's (show pictures to explain this). If it is not, assume the page is NOT from the bank despite the https.

We believe this simple steps can help make a dent in phishing and identity theft, saving banks a lot more money than spent on making the changes to be compliant with the above policies.

The changes should be simple to implement by your service provider and web master, but may require acquiring new certificates. It is all fairly standard technology.

Copy of presentation and videos from the symposium

A copy of the presentation and videos used at the Symposium on Usable Security and Privacy is now available here.

StraightTalk Blog Article

Here is a link to further technical discussion on why it is critical to avoid login boxes on insecure pages - by one of the co-authors:


http://www.straightsectalk.com/?p=44#more-44

Study on Bank Site Security Design Flaws

This blog concerns our recent paper on prevalence user-visible design flaws at financial web sites that will be presented at the Symposium on Usable Security and Privacy on July 25th, 2008 in Pittsburgh. Here are the key links:

• Full paper: Link to the full paper at the symposium web site
• SOUPS conference presentation and videos (also includes recommendations for designing secure web sites for our concerns)
  
• My home page can be reached at Atul Prakash
• Link to my Kevin Border's security blog: http://www.straightsectalk.com
• Other links in one place (news,etc.)
• Our source for list of financial institutions (mostly U.S. banks)

DNS vulnerabilities and impact on the study

Recently, there have been reports of serious vulnerabilities in the Domain Name Service software. Domain Name Service translates hostnames (e.g., www.chase.com) to its Internet Address (e.g., 159.53.60.105).

CERT has issued an advisory on this and asked everyone to patch their servers. 

Vulnerabilities such as this could theoretically allow even remote attackers to misdirect customers to spoofed pages of their banks, especially if banks do not rely on SSL for all their content. 

I would urge all banks to switch entirely to SSL for *all* the content as soon as possible. 

Most users do not type "https" prior to the URL. To handle such cases, the home page should immediately be redirected to a secured page. See www.fidelity.com, www.bankofamerica.com, www.wellsfargo.com for examples of that redirection.

With the correct use of SSL by banks, customers must also be careful.  A careless customer can continue to be vulnerable if he/she does not pay attention to the hostname in the URL and the use of https prefix, or ignores certificate warnings from their browser. If banks consistently use SSL, careful customers should check the URL to make sure it starts with https://xyz.your-bank-domain.com/... and  should not ignore warnings from their browser.