Don't count on a bank handling data security well.
Here's a story for ya', I won't use the bank's real name, but it rhymes with HSBC.
Anyway, a while back, I was logging into my online banking and the password no longer worked. So I called tech support to see what's up. They said, oh yeah, your password can't be more than 8 characters now. If it was more than that previously, it got truncated [not sure they actually used that word], so try the first 8 characters. So what does this tell you about the way they were/are storing my password?
+1 for frisco (hopefully most of us) that understands the basics of a one-way hash!! The more precise answer is they at least were storing password in plaintext.
It could be that the bank was hashing the passwords all along, but just truncating the user's input before hashing it and comparing it to the saved value. Not that I think this is what happened, but I'm just saying it could be.
If they did that, his old password would still work. His use of "no longer" implies that the password used to work before the policy change.
Unless at some point they started rejecting long passwords just for being long, without checking them against the database. And this is just not plausible.
From their point of view, if someone can read the database on their mainframe, that's already doomsday. They put all their security outside that perimeter, but no further layers like encrypting table columns inside.
They store passwords the same way they've always stored PIN codes (where encrypting would be pointless): there's a ALPHA(8) field right next to the NUMERIC(4) field for your PIN. Those design decisions are from an era where adding an extra VARCHAR(64) to store a MD5 password times 100 million accounts cost real money. It was probably the right decision.
Rather than sneer at the older generation, try to see the constraints they worked within. It opens your mind to imagine what "right decisions" now will seem silly to later generations. Non-GC languages with threads kludged in? Program syntax limited to ASCII? Silicon? IPv4 & NATs?
Online banking system have not been around that long. I do understand banking systems (the legacy stuff) and online banking (the newer front end stuff) particularly well as I built some of them. When I say built, I mean the company I founded wrote the code and I was the lead architect for what was used in many online banking systems.
Access to your accounts online should entail a system just for online access which is separate from and has a tightly controlled internal interface to the legacy bank system. I realize some banks may not have done it this way.
I spent my early career integrating with and sometimes replacing legacy mainframe systems. I have much respect for the old constraints programmers had. If a bank gets their online access wrong for anything written in the last 10 to 15 years its probably due to a decision to not architect the solution properly rather then a programmer being ignorant.
Fuck encrypting the email itself -- it should only contain a link to an https site that the intended recipient has credentials to log into (preferably with multi-factor auth). This is what real, grownup banks do!
My understanding is they were breaking regulation by not. The company I work for does customer opinion surveys. We occasionally do some for a large national bank. When we send data, of any form to the bank we are required to encrypt the email before we send it. This is just for something like random customer surveys not even at the level of actual account data.
What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place?
Maybe the employees were so irritated with Microsoft outlook they have been using Gmail instead. But seriously if I were a member of that bank I would be withdrawing my money right away. If there security procedures are so lax that they send a confidential email such as that through Gmail then they aren't responsible enough to hold anyone's money.
"Hi, you received an email from us yesterday with confidential information. Please contact us immediately and destroy the file. It's the email with the subject 'Re: Do we have a way to back up our data?'"
There's absolutely no reason for it to have been done. That type of information should only be available to pre-approved, secured email addresses. And that certainly should be a company.com address, not gmail.com.
The only plausible "excuse" would be that an employee decided to take a shortcut thinking that no harm would be done (and no one would know) and had a "oh f*ck!" realization when it went to the wrong address (and don't they wish they were using GMail with Undo!). This is still unacceptable. If it was a common and accepted practice, it's inexcusable.
What the fuck was a bank doing sending the confidential information of thousands to a GMail account in the first place?