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.]
Barclays do not deactivate autocompletion entirely. Their login process requires (1) your surname, (2) your 8-digit “membership number”, (3) your 5-digit online-banking PIN, and (4) two letters of your self-chosen memorable password entered via pull-down menus. Both items (2) and (3) are nonces chosen by the bank and are not used anywhere else other than for their web site login. Items (1) and (2) are autocompleted if you chose so. Whether you want autocompletion for your membership number or not is stored in a cookie. Sounds all rather carefully engineered to me.
I suspect that this is not autocompletion (where the information is held by the browser), but that the information is held in a cookie, or on the server linked to a cookie. I think the end result is the same though.
The cookie should be linked to the bank domain name, so the phishing site cannot get access to it. The phisher can thus not fill out the form with what the user expects.
No, as Markus says, the two text fields on the Barclays online banking front page don’t have the autocomplete=”off” attribute; nor does the password form on the next page. I believe that the pull-down menus for the memorable word letters were introduced as a measure against key-loggers (previously they were conventional <input type=”text” …> fields); I don’t know whether Barclays actually established that most of their users select from drop-down menus with the mouse rather than the keyboard….
On a side note…
My Bank asks for a Social Security number and PIN to authenticate to online banking (yes I know not very good attributes to use). Well the last time I logged on they introduced a new scheme that has the user select a picture from a list of at least 100. Many on these were pictures or rather strange objects. After the user does this they assign a string to the picture, presumable a word that the users can relate to the picture. Subsequently after the user identifies themselves, but before they enter the PIN, the picture and string are displayed.
I assume one of the intended reasons for this is to help thwart phishing attacks…
You are quite correct about autocomplete being enabled, but the checkbox Markus describes doesn’t seem to have any effect on this. I don’t have a Barclays account, so I can’t check, but I suspect the two systems are orthogonal.
Attempting to log on with invalid details and selecting the checkbox doesn’t make any difference. I expect that after logging in with valid details, a cookie will be set recording your account number for next time. Can anyone confirm this?
Forcing the user to type a password, or something similar, is useful in demonstrating intent – e.g. the intent to enter into a contract.
Without disagreeing with Steven’s analysis, I am uncomfortable that the bank (or more precisely, staff within the bank) has access to my password. I would prefer a mechanism such as use of a client-side SSL certificate to authenticate me to the bank. Even if I allow my workstation to cache the password used to unlock my certificate the bank never learns that password.
Unfortunately, I realise that these are harder to explain to users, especially those who use several different computers to access their bank accounts.
yeah, it just sets a cookie containing your surname and account number concatenated. However, slightly alarmingly, all of the ibank.barclays.co.uk cookies appear not to have the “only send on an encrypted connection” flag set. That said, if you go to http://www.ibank.barclays.co.uk/ (which just redirects to the https version) the cookies aren’t sent, by Mozilla at least, so perhaps this is the default behaviour for cookies set by an encrypted page (or perhaps it’s the result of the “only return cookies to the exact site which set them” option).
From steven’s commentary:
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.
Ok so we can all play games at estimating the mental capacity and processes of non-experts in security. But my suspicion is that someone savvy enough to spot auto-complete failing to complete is savvy enough to take phishing with a pinch of salt. This would tend to unwind the economic analysis based on autocomplete reducing fraud.
I think what is economically more significant is that autocomplete should make life easier, thus encourage greater uptake = more profit for banks. Maybe the twist is this: autocomplete encourages naive users to forget their passwords and become dependent on it. This reduces their mobility… they end up only using the one machine to internet bank. Therefore they get less value out of the service and don’t use it so much, therefore the bank still has to pay for the human teller that they visit when they nip out to the bank at lunch to make a manual transfer. just a thought.
I don’t quite understand how one can leave privacy issues aside when discussing autocompletion, nor why this discussion is focused on the individual and their household. I had the impression the crucial problem was public machines more generally – at work or in internet cafés or in libraries, etc. Websites storing sensitive information cannot rely on the admins at such institutions to disable autocomplete for login information, nor on even casual users not circumventing it. Provisions against autocompletion therefore reduce (though they don’t eliminate) the risk of a complete stranger discovering your login information and sensitive data. Bottom line: how many banks want to be sued for failing to include an autocomplete attribute or two?