'Verified by Visa' Forces Users to Select Weak Passwords
blog.zorinaq.com
blog.zorinaq.com
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.
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.
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.
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).
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.
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.