Why are banking passwords so weak?

Question

Out of interest and because it infuriates me, I was wondering if SOmebody here might happen to work for a bank or otherwise know the answer to this.

I've used a few online banking sites (UK and N.America) and they universally enforce a password pattern of /[\w\d]{6,8}/ Sometimes, maybe you get to use underscore, but never ever do you get to have /.{6,20}/ that you get (more or less) with just about every !banking site you'll encounter.

I have been told that this is to do with storage space, but the maths don't seem to support that. Assuming that banks keep shadow tables for your password record, let's generously say an average of 10 per account, then doubling the allowed length of the password and doubling the bit width of the character set based on an 8char 8bit existing format means an extra 11*2*8 = 176 bytes per account, so ~168Mb per 1M accounts. Let's say it's a gigantic bank supporting 100M accounts - that's still only 16Gb!

It can't be that simple can it? Surely my numbers are off base.

Or is the answer here that banks being banks they have no better reason for this than they're plodding dinosaurs.

Does anyone know a technical reason why my password for www.random.com/forum is stronger than the one for my bank?

Answer 1

If the stories I've heard about certain banks are true...

It's because whenever you enter your password:

• The web server sends it over a half-kilometre-long serial cable to an old 386 in an abandoned office, running the UI (Compiled using a custom-hacked version of Borland C 1.0) that was used by bank managers in 1989, which doesn't have a serial interface so it has to go through another device that simulates keypresses on an AT keyboard.
• This program inserts your request including your password (encrypted using a custom algorithm that's too weak to be used anymore but which cannot be disabled in the software) into a FoxPro database on a NetWare file server in a different abandoned office at the opposite end of the building (just because it would fall to bits if they tried to move it.)
• Back in the 1st abandoned office another old 386, constantly polling the FoxPro database for new records, detects this request and forwards it over an even slower serial cable (this time in EBCDIC) to another box in a 3rd office that is emulating a PDP11 running the actual COBOL program that maintains the accounts.
• Unfortunately they also still need the real PDP11, because it had custom microcode for another secure encryption algorithm (which they can't extract or the anti-tamper device will erase it.) The PDP11 can't handle the increased workload of all accounts opened since 1981 (the year of their first unsuccessful attempt to retire it) so now (via another layer of screen scrapers and emulated hard disks) it is tricked into performing a subset of functions (including password verification) on behalf of the main server.

So your password can only use the common subset of the character sets supported by all these systems, and can only be as long as the shortest database field involved.

Answer 2

I actually work in a bank right now, and have worked in quite a few in the past.

The primary reason that this happens is that in general the people who are ultimately responsible for making these decisions are not the people who end up implementing them. The "Business Unit" of a bank are the non-technical business experts who end up making these decisions. In many cases, technical objections will be overruled for political or business reasons. But this isn't exclusive to banking. It happens in any industry where technical considerations are often not the primary concern.