Hacker News Reader

Comment by jhancock | Hacker News Reader

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?

View on HN

(Hint: you can't truncate a hash and get a subset string of the original password to still work.)

+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.

Then would would the newly entered shorter value match to?

123456 -> hash code 1

123 -> hash code 2 (which doesn't exist in their db)

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?

Encrypting passwords protects against insider attacks also, so it would still be a benefit.

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.

Reply on news.ycombinator.com