Hacker News Reader

Comment by timbowhite | Hacker News Reader

Chase's online banking login is case insensitive (for both username and password). Frightening that a bank cares less about security than letting people in.

View on HN

I don't know how things are in the states, but a lot of banks in the UK ask you to input randomly selected characters from your password rather than asking for the whole thing. This suggests they're storing the passwords in the clear. The financial times wrote an article about it recently:

https://www.ft.com/content/33503e4a-8f95-11e6-a72e-b428cb934...

I'm sure that is also preventing lots of people from using randomly generated passwords.

I do, and it's not fun when I get asked to type in the 12th, 13th and 15th character.

This is because a lot of banks Internet banking systems evolved from their phone banking systems. The random digits thing was so that someone couldn'the guess your code when you said it out loud over the phone.

Yes, when I wound up with Fidelity for a 401(k) I found their system was designed around being able to "enter your password on your phone" -- using the number keys, i.e. b3G -> 234. I can only hope that version is at least stored as a hash...

The worst feeling is getting halfway through keying out your password on the number keys when the Fidelity robot tells you that's not the right password. I just say operator now until they transfer me to a human.

I apparently am "good" enough to never have had that happen, though I don't call very often. That's horrific, since it implies that it is stored as plaintext, "optimistically" as "plain-number-text."

It's also horrific because you can use that to brute-force guess someone's password, because the robot will tell you when you have the wrong digit, so you can work your way through all 10 phone keys for each digit, noting each time whether the robot kicks you out, until you guess the entire thing.

To be clear, the input just times out, likely because they don't expect a long random password input. I don't think it's evidence that they can verify a substring of your password.

Agreed. Their rationale is that keyloggers can't as easily work and their chance of being hacked is lower than the odds of a user with malware keylogging :(

Probably true for the most part, given the nature of the user base. On the other hand, Tesco Bank got owned this week.

Card-readers and other two-factor authentication is a better defence against keyloggers.

They could hash all the possible triplets. This would be still ridiculously easy to crack, but it's not cleartext anymore so maybe it would pass the tick box security audit this way?

I was in my bank branch recently and they printed off a statement while I was there. It was only when I got home I noticed the url was http rather than https. It was an intranet but even so.

So if someone breaks into one branch, they break into every branch?

Yay! Free bank accounts all around!

It's possible the machine has some kind of VPN connection and this encryption is indeed end-to-end, just at another layer.

More probably: the branch itself has a hardware VPN, so compromising the local network is still possible.

My bank in the UK has two separate things - a password, which I have to enter in the whole, and a "memorable word" which acts as you suggest. I've not seen a bank account which solely uses a memorable word.

Santander uses selected digits of PIN and selected characters of password, with a numeric user ID.

In fairness to them, they do use 2FA for anything involving moving money around.

Ouch, yeah, Santander. Worst bank in the UK. Everyone I know who uses them has had some really terrible experiences.

A common interview question for penetration testers is how you might design password storage to allow this 'feature' without having to store the plaintext password. It's possible, I guarantee it.

That sounds interesting. Can you explain how to do it?

https://en.wikipedia.org/wiki/Secret_sharing

SSS doesn't look like it pertains to this discussion at all. How do you use this to store single digits securely?

If you have an method for requiring n out of m key parts to use the key, it is fairly easy to see how this can be used to require n out of m characters from a password. The only problem is that just a few characters doesn't have a large enough entropy to prevent the whole thing being brute forced very quickly.

> If you have an method for requiring n out of m key parts to use the key, it is fairly easy to see how this can be used to require n out of m characters from a password.

It doesn't sound very easy to me at all. Can you explain in more detail?

How? I would be very interested in a solution for that, past the obvious and insecure "hash each character separately".

The last time I was made to change my Chase password, I made it maximal length at the time (32 characters). However, it turned out their login page had an off-by-one error in the login page Javascript, such that it wouldn't let you type 32 characters in the field. I worked around it via using the browser debugging tools to fix the bug, then decided on a 30-character password as an additional margin of safety. They said they'd look into it, never heard back about it.

Finding off-by-one errors in production code is a hobby of mine, but it's also pretty horrifying how often they're security-relevant.

You're lucky they didn't send a SWAT team to your door for "hacking."

I get the case insensitivity on the username though. You don't want grandma trying to remember if it was SweaterKnits@aol.com or sweaterKnits@aol.com as they resolve to the same thing. If not using the email, then he same thing applies, and I don't want the hassle of my tech support trying to resolve the difference over the phone.

In general Chase has a reputation for being much more careful and thoughtful about security than others (and in fact their password policy is somewhat better than some other financial institutions I've done business with). But still, I agree, that sucks.

e: There is a pretty good discussion of this here https://www.reddit.com/r/personalfinance/comments/2m81uj/tip...

This is common with banks due to legacy systems that don't have case sensitivity.

It's also not unheard of for them to strip all non alphanumeric characters so P@ssw0rd2016! is normalized to pssw0rd2016

Frightening that a bank cares less about security than letting people in.

On the other hand, they are probably far more alert to detecting and stopping bruteforcing attempts.

It's a similar situation with certain 4-digit PINs for smartcards; that may seem trivial to bruteforce, but you only get 3-5 tries before the system considers you to be attacking it and permanently locks you out even if you try to enter the correct one afterwards.

I don't think that's correct, the password field is case sensitive for me.

As mine is too. Just tried it and it said incorrect. Maybe it's some set of old legacy users? But that wouldn't make sense since I'm migrated in from WaMu

  Chase's online banking login is case insensitive ...

So is the case with Citi.

This is not true (at least for passwords on Android).

My bank used to do this as well.

Reply on news.ycombinator.com