I always get double freaked out when I see requirements like that, because I assume that the "special characters" restriction is required for some homebrewed crap rot13-style idea they have for obfuscating the passwords instead of hashing them. I literally can't imagine how such a restriction would arise unless they have a bigger problem.
Your paranoia is more generous than mine. Such restrictions always make me assume that they don't know how to properly sanitize data for their database, so they just disallow such characters rather than learn how.
I always assume there's old mainframe code involved whenever I see a requirement that says "less than 8"
Especially in the financial sector.
Mainframes are weird. They are still used in a lot of places and don't play by sensible rules. People still run these systems with 24x7 operations staff, as in, there is someone sitting in front of the mainframe console at all times.
It is a crazy world out there and a lot of people still use these systems to do terrifyingly important things.
Mainframes are still in use partly because (until perhaps very recently), they are bar-none when it comes to high-availability and disaster recovery.
I did some work in COBOL on a Unisys mainframe back in the late 90s, and I'm still impressed by that thing. You could walk over, pull the plug on it while it was in the middle of running a payroll job, a finance job, and half a dozen other things. Plug it back in, wait a few minutes, and it would pick up right where it left off. No data corruption, no other hassles.
Migrating away from that thing was often discussed, but it would have been a tremendous hassle. For one, there was no simple way to migrate the huge volumes of data off of it; for another, even if you could, decoding it would have been a neat challenge. Then there was the matter of all the years of business logic that, while not pretty, worked with very few problems.
...and this was just for a school district in the East Bay. I can't imagine what it would look like for a big financial company.
Mainframes are very much impressive, I've worked with one before. They just operate very very differently from an "open computing" environment that we're all used to.
Once you rely on a mainframe the cost of continuing to operate it, while fairly large, is hilariously less expensive than moving all that code and data elsewhere. Especially given you will have to test all the code again and most people don't even know what it all does anymore, much less how to make sure it's doing it correctly.
That was the excuse one major bank or credit card company gave a while back (I don't remember for sure which institution it was, which is why I'm not naming it). Basically, they said that user accounts on their mainframe used 8 character login passwords, so that's why your online banking password was limited to 8 characters.
That was, of course, complete bullshit, for a couple of reasons. First, bank customers would not need accounts on the mainframe. A bank customer account would be defined by an entry in a database running on the mainframe, not by a user account on the mainframe. The bank system would essentially be an application running on the mainframe, and bank customers are data for that application.
Second, even if we give them the benefit of the doubt and assume they were really talking about some other kind of password on the mainframe (maybe the database records for each customer are encrypted with a password, and the mainframe's cryptography software can only deal with 8 characters) and so there really is a backend limit of 8 characters, there is no reason that has to imply a limit on the password length for online banking. The web-based front end to the banking system, which is what the online banking customer actually interacts with, can have its own, modern, password system without any such restrictions. There's no reason the 8 character password for the mainframe has to come directly from the user--it can be derived from the front end password.
I didn't think you were saying it is a good excuse. I was just offering an example to support your suspicion that mainframes are the (poor) excuse the banks use.
One core financial system I'm familiar with obscured the home banking passwords by storing them in EBCDIC. It's trivial to recover them as long as you know the encoding. It had similar restrictions, including length.
The same system does in-flight encryption (client communication to server) using a trivial byte-based XOR cypher, with the offset communicated in the clear when the connection is established.
Unless I'm missing some technical trick, passwords are actually stored in plain text, not hashed at all. My reason for this assumption is that in some cases (I think it depends on card provider), instead of typing in the password, you just type in 3 specified characters from it (e.g. "please enter the 3rd, 5th and 6th characters"), certainly this is the case for my Visa debit cards from Barclays.
Is there any way they could verify a single character against a hash, or am I right in thinking it has to be stored plain text?
So many websites have annoyingly dumb password rules, just yesterday I was told that my "use this on a bunch of sites I don't really care about" password (which is long and contains upper/lower/numeric/special characters) couldn't be used because it had "recurring letters", i.e. the same letter was next to itself in one occasion. Therefore my password for that site is now "fuckingcunts", in my childish hope that some day that company will ask for my password over the phone.
If it were possible to verify a single character in a hash, then you could attack a hash by verifying the first character, then the second character, etc, until it results in the hash.
You could store hashes of various small combinations, e.g. hash the 3rd, 5th and 6th characters and then test against that. Then nothing needs storing in plain test. You don't even need to store the hash for the whole password either.
American Express does the same thing!! My user name is actually twice as long as my password by virtue of their restriction.... It seems like they're actually hoping for a PR disaster.
Well, the idea is that your account is irrevocably locked out if you guess the password wrong 3 times. So the size of the keyspace does not really matter. The attack on this system is calling Visa and pretending to be you, not guessing passwords.
Remember: when you are using a credit card, you are spending the bank's money, not your own. So if the bank doesn't want you to use a long password, it's their loss when someone compromises their database. You say "that charge was not authorized" and the bank eats the loss.
This is different than an email or Twitter password, because when someone compromises your email or Twitter account, the damage to your reputation is your problem. But credit cards are different: it's not your stuff at stake, so you shouldn't really care about how they do security. Their goal is to reduce fraud without stopping you from using your card.
Remember: when you are using a credit card, you
are spending the bank's money, not your own. So
if the bank doesn't want you to use a long
password, it's their loss when someone
compromises their database. You say "that
charge was not authorized" and the bank
eats the loss.
The bank doesn't eat the loss either. They'll just turn it into a charge back against the merchant.
Verified by MasterCard or whatever their program is called has the same restriction, and it doesn't make any sense. First time I saw the form I called my bank to verify that I was supposed to be seeing that form and that it was safe to enter my data.
My banks password system is terrible. It must be between 6-8 characters long, and no special characters allowed. When I originally created my password, I didn't read the rules and typed one of my "usual" ones in. It consisted of a dictionary word, followed by a series of numbers and special characters.
Because of their inferior UI, I never noticed my password was getting truncated at 8 characters long, which just so happens to be the length of the dictionary word. For almost 4 years my banks password was an eight character dictionary word instead of the 'slightly more secure' 14 character version I thought I was using all along.
I would much rather visa allowed generation of single use CC numbers backed by a user-specified monetary amount, for online shopping. I think discover card used to do this (not sure if they still do). That always seemed like a better idea to me.
30 comments
[ 2.9 ms ] story [ 95.9 ms ] threadEspecially in the financial sector.
Mainframes are weird. They are still used in a lot of places and don't play by sensible rules. People still run these systems with 24x7 operations staff, as in, there is someone sitting in front of the mainframe console at all times.
It is a crazy world out there and a lot of people still use these systems to do terrifyingly important things.
I did some work in COBOL on a Unisys mainframe back in the late 90s, and I'm still impressed by that thing. You could walk over, pull the plug on it while it was in the middle of running a payroll job, a finance job, and half a dozen other things. Plug it back in, wait a few minutes, and it would pick up right where it left off. No data corruption, no other hassles.
Migrating away from that thing was often discussed, but it would have been a tremendous hassle. For one, there was no simple way to migrate the huge volumes of data off of it; for another, even if you could, decoding it would have been a neat challenge. Then there was the matter of all the years of business logic that, while not pretty, worked with very few problems.
...and this was just for a school district in the East Bay. I can't imagine what it would look like for a big financial company.
Once you rely on a mainframe the cost of continuing to operate it, while fairly large, is hilariously less expensive than moving all that code and data elsewhere. Especially given you will have to test all the code again and most people don't even know what it all does anymore, much less how to make sure it's doing it correctly.
That was, of course, complete bullshit, for a couple of reasons. First, bank customers would not need accounts on the mainframe. A bank customer account would be defined by an entry in a database running on the mainframe, not by a user account on the mainframe. The bank system would essentially be an application running on the mainframe, and bank customers are data for that application.
Second, even if we give them the benefit of the doubt and assume they were really talking about some other kind of password on the mainframe (maybe the database records for each customer are encrypted with a password, and the mainframe's cryptography software can only deal with 8 characters) and so there really is a backend limit of 8 characters, there is no reason that has to imply a limit on the password length for online banking. The web-based front end to the banking system, which is what the online banking customer actually interacts with, can have its own, modern, password system without any such restrictions. There's no reason the 8 character password for the mainframe has to come directly from the user--it can be derived from the front end password.
The same system does in-flight encryption (client communication to server) using a trivial byte-based XOR cypher, with the offset communicated in the clear when the connection is established.
There are big problems out there.
Is there any way they could verify a single character against a hash, or am I right in thinking it has to be stored plain text?
So many websites have annoyingly dumb password rules, just yesterday I was told that my "use this on a bunch of sites I don't really care about" password (which is long and contains upper/lower/numeric/special characters) couldn't be used because it had "recurring letters", i.e. the same letter was next to itself in one occasion. Therefore my password for that site is now "fuckingcunts", in my childish hope that some day that company will ask for my password over the phone.
So nope. Not possible.
Remember: when you are using a credit card, you are spending the bank's money, not your own. So if the bank doesn't want you to use a long password, it's their loss when someone compromises their database. You say "that charge was not authorized" and the bank eats the loss.
This is different than an email or Twitter password, because when someone compromises your email or Twitter account, the damage to your reputation is your problem. But credit cards are different: it's not your stuff at stake, so you shouldn't really care about how they do security. Their goal is to reduce fraud without stopping you from using your card.
I am guessing you did not read the end of my post giving 3 other reasons why the keyspace size does matter (no. 1 being for PCI DSS compliance).
Because of their inferior UI, I never noticed my password was getting truncated at 8 characters long, which just so happens to be the length of the dictionary word. For almost 4 years my banks password was an eight character dictionary word instead of the 'slightly more secure' 14 character version I thought I was using all along.
I would much rather visa allowed generation of single use CC numbers backed by a user-specified monetary amount, for online shopping. I think discover card used to do this (not sure if they still do). That always seemed like a better idea to me.