Most web browsers are happy to remember user’s passwords, but many banks disable this feature on their website, shifting the task to customers. This decision might have been rational when malware was the major threat, but doing so hides a cue shown when a known website changes its address. The rise of phishing could thus make their choice counter-productive. We discuss why.
“Autocompletion”, provided by Mozilla/Firefox, Internet Explorer and Opera, saves details entered in web forms, including passwords. This improves usability, as users are no longer required to remember passwords but has some adverse effects on security (we leave aside the privacy problems). In particular, passwords must be stored unencrypted, so putting them at risk of compromise, both by other users of the same computer and malware on the machine. Mozilla improves the situation slightly, by allowing the password database to be encrypted on the hard disk, and unlocked with a master password. However, this is not the default so few will use it; in either case if the browser is left running other users can exploit the passwords, and malware can take them from the process memory.
For this reason, many banks have disabled password autocompletion, by adding autocomplete="off" to the form. This prevents Mozilla and IE storing the password (Opera ignores the website’s request), so resisting the above threats, but does it introduce more problems than it solves? By being imposed with the responsibility of remembering his password, the customer might reduce security in order to manage. He could write down the password and keep this near the computer or on his person; this allows secure passwords but is at risk of compromise by those with physical access. Alternatively he might choose a easy to remember, low security password, and/or use the same one on multiple websites, introducing vulnerabilities from electronic attackers.
More topically, autocompletion resists phishing attacks. A form field is autocompleted if it is at the same URL (IE) or same hostname and field name (Mozilla) as when the password was entered. If a potential victim is sent to a phishing site, autocomplete will not trigger, hopefully causing the user to investigate the site more carefully before remembering and entering the password. Rather than making entering a password a reflex action, autocomplete turns it into an exceptional case, allowing and encouraging pause for thought. However this will not happen for banks; all those I was able to test disabled the feature (Halifax, Egg and Lloyds). Does this improve the security, or just allow banks to shift liability onto customers? Is it the result of a carefully performed risk analysis or simple a knee-jerk reaction against a new feature, more the result of folk-wisdom than sense?
Security economics might help answer these questions. A simplistic analysis is that autocompletion resists phishing but increases the risk of malware and fraud by members of a customer’s household. Deciding on the best course of action requires access to detailed fraud statistics, but the banks keep these as closely guarded secrets. Nevertheless, something still can be said about the comparative risk to customers of the above attacks. Anecdotal evidence suggests that fraud through malware attacks is small compared to phishing, so that just leaves intra-household fraud. At least after the fact, phishing can be easy for the customer to deny. He might have the email, and the transactions are typically international. Fraud by members of a household is considerably more difficult to refute; the transactions might be in person, leaving less of an audit trail and are likely to be local. So rationally banks should enable autocompletion, reducing phishing attacks which they have to pay out for and shifting fraud to the household, which they can pass onto customers.
But the banks haven’t done this. Have they just not thought about this, or does the evidence justify their decision? I welcome your comments.
[Thanks to Ross Anderson for his comments on this issue.]
