New Security Vulnerability: Clueless Users

I can’t make heads or tails of this story:

A security loophole at a bank allowed easy access to sensitive credit card information, the BBC has found.

The Morgan Stanley website allowed users to access account details after entering just the first digit of a credit card number.

The shortcut would only work if the account holder had set up the computer to automatically save passwords.

It seems to me that if you set up your computer to automatically save passwords and autofill them onto webpages, you shouldn’t be surprised when your computer does exactly that.

Tags: , , , , ,

Posted on November 22, 2004 at 10:24 AM • 27 Comments

Comments

Nick Barron • November 22, 2004 11:25 AM

It’s worse than that. Apparently if your write you PIN on your cashpoint card and then lose it, someone can access your account.

Apparently, although I haven’t yet confirmed this, it’s also bad practice to leave all your money in the street.

As they say, you can’t fix stupidity with software!

Phil • November 22, 2004 11:25 AM

I think the bank does need to take stupid users into account. You can design a web-page so that it will not allow the browser (IE, Mozilla, Firefox… not sure abot Opera) to save login/password info. My company (a bank) and another bank (I have an account at) will not allow you to store the username/password in the browser whether you have the option enabled or not.

Andrew Sweger • November 22, 2004 12:39 PM

To Phil, regarding web pages that do “not allow the browser to save login/password info”.

This is not true. A web page cannot prevent the web browser from storing this information. I’m sure you’re already aware of this fact, but it’s worth pointing out. I am frequently frustrated by sites that “force” that feature on me. I need to see about finding or making an extension for Firefox that instead warns me that the web site in question strongly recommends against storing the username/password information for autofilling later. It’s my machine and feel I should be able to do that if I want. Of course, the feature is just dandy for all those users out there who can’t or won’t take responsibility for their own security.

Philip Storry • November 22, 2004 1:10 PM

To Phil and Andrew Sweger…

I think you’re both on the wrong track anyway. My Bank requires me to have a certain number of a certain length as a passcode for telephone banking and internet banking. They ask me for a random three digits of that number whenever I try to use the service.

My browser (or my phone’s autodial on touch tone) could be programmed to memorise what I entered, but it’ll change next time anyway – a different three digit combination each time.

It’s a far better security solution, which makes the potential security hole (browser form autofill) completely useless. Well, if you implement good repeated-try-lockouts, anyway. 😉

Oh, and it’d save you time as a developer – you don’t need to keep the website up to date for the latest browsers – the form is processed server-side via SSL, and if it’s basic HTML I could use it via Lynx if I wanted to. Compatibility, security, and low maintenance. I think Phil’s solution sounds far too complex, and he’ll have to pick just two of those… grins

This is practiced by a number of banks in the UK, by the way. Some use passphrases instead of numbers, but the net effect is the same. I like the feature – it works very well, IMO.

Michael Koziarski • November 22, 2004 3:13 PM

It’s true that the browser can save whatever it wants irrespective of the wishes of the bank creating the application. However, the autocomplete=”off” attribute on input elements is honoured by most browsers. Typically browsers which don’t honour it are prevented from accessing the system.

What’s even more disturbing, is that all credit card numbers start with a 3,4 or 5. … Easier to guess than most login ids.

Tim Green • November 22, 2004 3:19 PM

My bank goes as far as asking for random characters from a numerical pin and from an alphanumeric password. Funny how I hated the change when it was brought in a few years ago …

Timm Murray • November 22, 2004 3:24 PM

Michael (above) is correct, but it’s actually worse than that. The first few digits identify what company the credit card is under (Visa, MasterCard, etc.) A given bank probably gives out cards under only one company. Only about 10 digits of any given credit card number are completely random (the last digit being a checksum).

piglet • November 22, 2004 4:17 PM

I just made the test. Despite switching on AutoComplete, the browser didn’t store the passwords on any of the banking web sites I use. They all have AutoComplete=”off”. AutoComplete can be configured to store everything without even prompting. This simply shouldn’t be possible! I think Schneier is wrong to blame users’ stupidity for that. If sensitive passwords can be remembered without even telling and asking the user, it’s bad security from the browser maker and the web designer.

Apart from that, Philip Storry has made a good point: It is bad security for a sensitive banking application to rely on a single password.
However, his UK bank’s three digits
solution seems again to rely on a single password. Many European banks use transaction codes. I am aware of two versions of the mechanism. In the first, the customer receives a list of codes that they have to enter, one by one, before each transaction. The second version is like a bingo card: the system asks the user to enter a specified code from the card. In both scenarios, an attacker cannot initiate a transaction even if they know the password, unless they are in physical possession of the code card.

Jeremy Hilliker • November 22, 2004 4:47 PM

To Phil, while it sounds like a good idea to prevent browsers from storing form data, this just furthurs the arms race between users and programs.

If a user wants to save data, then they should be allowed to. You’ve come along and asked for data not to be saved. The user, in turn, will say “I really want to save this data,” to which you will respond “I really don’t want you to save it,” to which the user will respond “I really really want to save it,” ad infinitum. Eventually, you have to decide which side should win this argument, in most cases, it should be the user’s side.

In this case, Phil and Andrew makes an excelent point, perhaps we should respect a way to prevent clueless users from storing very sensitive data, since most browsers seem eager to store anything and everything ever typed into a web-form.

http://weblogs.asp.net/oldnewthing/archive/2004/02/16/73780.aspx

piglet • November 22, 2004 5:30 PM

To Jeremy, it’s not users who invent security vulnerabilities, it’s software designers. Once those vulnerabilities have been sold as “ease of ue”-features, users are ready to make use of them, in some cases without even being aware of it because they have never been told. The “arms race” isn’t between users and programs, it is between designers of sensitive systems and attackers, and it’s the designers’ responsibility to take the habits of ordinary users, as well as the standard or nonstandard behavior of their hardware and software, into account as far as possible.

Bottom line: a sensitive web site which doesn’t set AutoComplete=”off” and which relies on an outrageously outdated security model (single password) is an example of VERY BAD SECURITY. Ordinary users aren’t to blame for that.

Jefferson Ogata • November 22, 2004 6:58 PM

While it’s logically possible for a browser to save passwords regardless of the design of the web page, it is also possible to make this feature practically useless, by changing the name of the password field to a unique value for each login session so that autocomplete functions don’t know where to stuff the saved password. If the user’s browser is saving passwords, yes, an intruder might recover them with some mild cleverness, but that’s a far cry from the scenario where an unauthorized user fires up the user’s web browser, browses to the protected site, and is automatically granted access.

tblade • November 23, 2004 1:37 AM

My Internet bank uses a somewhat different approach to the whole username/password problem. They’ve issued me with a little password generator device. Whenever I need to pay my bills, buy some stock, get a lone or close an account, I visit their web site, punch in my 4 digit pin code on the device, followed by an eight digit lock code supplied on-site. Those 12 digits combined with the time and date as given by some atomic clock somewhere are used to generate a six-digit password, which I then enter as my once-up banking site password.

davee • November 23, 2004 4:29 AM

My bank uses the “type N random characters from your passphrase to login” approach.

My concern is that this means that, unlike other systems where ‘shadow’ (encrypted) passwords are stored, the bank must be storing the passphrase in the clear. Otherwise, it would not be able to determine individual characters of the ‘correct’ word – shadow/encrypted passwords normally take a hash of the whole password, after all.

Rijk • November 23, 2004 5:27 AM

I agree with posters that say any bank transaction should require something like a password generator. Relying on a fixed passwords for a single login that allows you to do everything is just not secure enough.

About this autocomplete=off feature: the Opera browsers prompts you for each site whether you want to save the user/password pair or not. But Opera has decided not to enable support for autocomplete by default. A sysadmin could enable it in a corporate environment.

Sites that disallow autocomplete are not really helping users I think: if you can’t let the browser remember the password, you are more likely to use an easy password, or to put a sticky note on your monitor. How does that make online banking more secure?

Shridhar Kumar • November 23, 2004 11:49 AM

In fact, there is an extension for Firefox to force- remember passwords. This is from the same author who has scripted the very useful privacy extension for Firefox: BugMeNot. Both “BugMeNot” and “Always Remember Password” extensions are available at: http://extensions.roachfiend.com/index.php

I myself have used BugMeNot but not the password remembering extension. So, I don’t know if it works as claimed.

Toby Hede • November 23, 2004 8:05 PM

I use a system that has a pin number but uses a custom keypad to allow me to enter the information, using mouse clicks rather than text entry. This prevents both the browser storing the information or a key logger from capturing the data entry. The keypad is randomised for each request, so mouse tracking cannot be used to detect which numbers have been selected.

https://ingdirect.com.au/Client/Main.asp

I have several online banking accounts, one used to use a similar system but has since moved to a vanilla-html password field.

Tim • November 23, 2004 11:57 PM

With Safari, you can choose to remember passwords on a site by site basis. Furthermore, each remembered password is stored in the users encrypted keychain. The keychain can be configured in several ways for each site: automagically fill in the U/P, to request a confirmation click before filling in the U/P, or to request the users keychain password before filling in the saved U/P.

john • November 24, 2004 6:38 AM

Obviously the bank can’t stop a browser storing a password, but it can prevent the browser from using the stored password to complete the form the next time round. There’s a plugin for the Squirrelmail webmail app that does just this, by randomizing the name of the password field.

If your banking website doesn’t do this, it is insecure, because someone might use it from a public computer which has got autocomplete turned on, and the next user (who has looked over your shoulder to see your account id) then has a simple way to access your account.

Your desire to make your personal machine remember your password shouldn’t count. If you can do it on your own machine, some bad guy can so the same thing on a public machine.

Peter da Silva • November 25, 2004 8:34 AM

You could reverse-social-engineer the problem. People are getting used to copying stuff from an image into a form to prove they’re not a computer program, so take advantage of that. “New security feature: please enter the word in the image below, followed by your pass phrase, or [click here] if you can’t read the image.”

It may actually help with some automated keylogging attacks if you varied the number of characters in the word. 🙂

Ken Kelley • November 28, 2004 11:04 AM

To those of you who said “It can’t be done.” I think you’re wrong.

As I’m sure you all know, the way web forms work is that the HTML to the user has an “input” tag, which has a “name” attribute. The user then puts something in the box and clicks “submit”. Your webserver gets a request with name-value pairs of data.

It’s common to use “userid”, “password”, “address”, etc. as the names of fields on forms, and browsers take advantage of that. That’s what allows my browser to guess what to put in under “address” even on a web site I’ve never been to before.

But there’s no reason to use standard form field names. You can randomize them, so the field for “password” will have a different name every time someone goes to your page. There’s no way a browser can cache that, no matter how much it wants to.

And, no, it’s not a programming nightmare to do this. A simple java servlet filter could handle it, and the rest of your codebase would never even notice.

suresh babu • January 12, 2007 12:23 AM

hai friend

we have developing one site .
in that site i went to tools -> options ->autocomplte -> check the remeber passrord.

but once click he login buttton i wun’t get the autocomplete password window.

plz help meee

deepthi • March 7, 2008 5:09 PM

I want to investigate the safety issues for the vulnerability of data daved in online storage facilities in detail so that I can proceed further. I hope you will reply me as soon as possible.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.