5 ms·

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 cr

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.

masterzora 15y ago
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.
djcapelis 15y ago
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.
- thaumaturgy 15y ago
  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.
  - djcapelis 15y ago
    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.
  - deleted 15y ago
    [deleted]
- tzs 15y ago
  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.
  - djcapelis 15y ago
    Sorry, you misunderstood me. I wasn't saying that any of this was a good excuse, just that it is probably the cause.
    - tzs 15y ago
      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.
oasisbob 15y ago
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. There are big problems out there.

masterzora 15y ago

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.

djcapelis 15y ago

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.

thaumaturgy 15y ago
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.
- djcapelis 15y ago
  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.
- deleted 15y ago
  [deleted]
tzs 15y ago
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.
- djcapelis 15y ago
  Sorry, you misunderstood me. I wasn't saying that any of this was a good excuse, just that it is probably the cause.
  - tzs 15y ago
    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.

oasisbob 15y ago

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. There are big problems out there.