views:

654

answers:

6

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?

+7  A: 

I vote for the "they're plodding dinosaurs" answer :)

Alex B
+22  A: 

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.

Andrew Rollings
this is essentially the same as the plodding dinosaurs argument then :)
annakata
Yeah, pretty much ;)
Andrew Rollings
+5  A: 

Probably most of banking systems were developed long time ago, when 8 character passwords were considered secured. I don't think anyone would consider brute forcing passwords from banking accounts anyway, 8 characters it still a lot. I bet all banks block an account after 3 attempts or so.

serg
If you have a list of account numbers, trying the same password over all accounts has much better chances of having a hit, without ever triggering naive login checks. OTOH, locking an account after three tries enables good denial of service attacks.
David Schmitt
This should be the accepted answer.
Brad Gilbert
You think the banking systems for the consumer websites were developed at a time when 8x8 passwords were standard? If someone who was working in the late 90's could verify that, I'd accept it - just seems unlikely (or waaaaay out of touch of them).
annakata
@annakata nobody said 8x8 passwords were standard. serg555 says 8 characker passwords were considered secured.
andho
+21  A: 

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.

finnw
I don't know how true what you describe is, but I am sure of two things: 1) now I am trembling in horror. 2) your comment is fantastic.
Stefano Borini
@finnw: Oh you've worked with California DMV too?
Spencer Ruport
+1  A: 

Here is a "bug" I got logged in Bugzilla regarding a site I'd built for a client recently (not a bank, thankfully!):

"It seems that the user is forced to use a ! or _ in their password* which seems a bit odd to me. Can this ben updated so that it is a 6 - 8 digit password that can only use alphanumerics?"

  • Actually, it was at least one non alpha-numeric character
Dan Diplo
+4  A: 

Banks use online services primarily as an interface to legacy systems. Your password is probably being processed by an IBM mainframe somewhere, written in Cobol, and the password structure may have been designed in the 70's.

In addition, because banks are such political structures, the management primarily sees "concrete" results so issues such as security are not addressed until it becomes a hot issue and then there is an "initiative" to address it.

At one bank I worked for, the production password was the same as the userid (same idea as logging in with "root" "root"). The user passwords could be reset online to a combination of first N letters of your last name + last 4 digits of your SSN, so any user could reset your password if they knew your name and SSN and loginas you .

Larry Watanabe
Is this from real experience? It is scarily similar to my (deliberately exaggerated) answer.
finnw
Yes, it is from real world experience.
Larry Watanabe