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.
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:
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?
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 :(
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.
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?
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.
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.
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.
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.
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.
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
