Disclaimer - not a security expert. Just a regular developer who reads a lot about security. Most of my opinions here are backed up by Troy Hunt's blog.

You're missing a thing - in most banks(all that i have seen, including 3 in Bulgaria and 4 in France) the online banking password is on a keyboard available on screen, with a button for each digit, each time randomly arranged, and you have to point and click to construct your password. Unless an attacker just throws random clicks at them, i don't see a way one could brute force his way through this.

@AdrianTodorov Who says an attacker would even be using that UI in the first place? They can just bypass the UI entirely and send the desired numerical codes directly to the server.

But even if they are using that UI, OCR for 10 digits is not difficult. A randomised on-screen numeric pad like that helps against a particular threat model: attackers who have a keystroke logger installed on the machine hoping to capture whatever passwords are entered, but who aren't logging the contents of the screen (for reasons of data size or otherwise). It's not designed to help against someone who can look and click, since that's all the user is.

Correct me if I'm wrong, but isn't it easy enough to thwart a brute force attack by locking accounts for an hour after six attempts? If a bank loses control of their database, I think they probably have larger problems than password length.

@RobertHarvey you would thwart brute force attacks, but you would make a DoS attack easier. 144 (=6*24) random combinations would be enough to block the account for 24 hours.

@A.Darwin: I hadn't thought of that. Does that mean locking people's accounts temporarily is not a viable technique? I know of several banks that do this; it's hard to imagine any bank allowing unrestricted password attempts just to prevent DoS attacks.

@RobertHarvey It's viable, it just has a potential downside that may impact customers. Most organizations are willing to accept the risk of DoS over the risk of account compromise.

@RobertHarvey a more secure approach involves "out-of-band verification". Basically, you can only log in if you enter the right password and confirm your access in a different way, typically via SMS (e.g. you have to enter a security code the bank sent on your phone). In this way, there is no need to block the account, so DoS attacks are mitigated while also reducing the chance of a successful brute-force attack (the hacker would need to get the security code from the SMS).Issues arise when you use the same device for the login and for the security code (a smartphone), but you get the picture.

@AdrianTodorov That is something I hate of the login. I'm a keepass user and the fact that I have to use the mouse means I cannot quickly copy&paste or autotype the password but I either have to learn it by heart of read it. Sure the randomly arranged numeric pad gets rid of a bit of shoulder surfing[citation needed] but I'd rather be able to use a 128 character completely random generated password by KeePass and don't ever have to actually even see it: just store it securely and let him do his stuff.

@AdrianTodorov I've never heard of banks using a randomised on-screen numeric pad as standard practice. Certainly it's not standard practice in the UK, and wasn't mentioned by the original poster in the question who explicitly said "password".

My original draft for my answer mentioned hard account lock outs etc, and the possibility of that enabling a DoS attack. To keep things simple I suggested captcha codes as a means to not lock legitimate users out but still discourage robots after a certain number of attempts. As I mentioned in my answer, a 2nd verification step preferably out-of-band, like codes sent to a phone is desirable.

"But if that is the reason, why on earth would they force you to use the same insecure pass code online (or on mobile), when you have access to a full qwerty keyboard?" - possibly so your grandma doesn't forget whichever password she uses less often?

I have been customer to a major bank in a developed country, and they also has the same scheme of log in. However, any request for past transactions or new transaction needs number from token generator. Even if someone managed to get through the login screen, it's unlikely they are able to do anything past that.

The bank will also lock the IP address is it detects suspicious behavior. Of course the hacker could use drones, but even if they get online access, the most they could do is send cash to pre-authorised recipients.

Why is it 72 for alphanumeric?

I don't think this should be the accepted answer. Most banks use this kind of security and they don't get hacked because of it. The interfaces to the databases are also strictly controlled and have to conform to stringent security standards. Unless you have inside connections you won't get at the database. The original poster need not stress too much. Banks do know what they're doing.

@user1751825 sorry, no. Most banks use this security and don't get hacked is a terrible excuse for weaker protection than my email account, twitter account etc. See troyhunt.com/whos-who-of-bad-password-practices

@v7d8dpo4 because I can't count. Have fixed it.

If you can guess the password of a user with probability P before the user is locked out, The probability that you won't guess the password of N users before they are all locked out is (1-P)^N; that is the probability that you'd gotten into one or more accounts is 1-(1-P)^N, and not as you suggest P*N. However, for large N this approaches 1, and N might be large enough quite fast (that is your suggested attack is effective, but your math is wrong).

@Ajedi32 i'd think a bank would have heard of simple techniques like CSRF and sessions to make it rather difficult to just POST a random value at a page :)

"making 3000000 requests would not take very long at all"... wouldn't their IP get banned after a handful of tries? How many IPs do you think an attacker can get their hands on?

@user1751825 You're rather optimistic about this bank. Even in the case of banking via telephone, why the 6 number limit? Why can't the user have a seperate password for their online account? Such a primitive password policy hints at fairly poor security knowledge, and I'm willing to bet they don't have much in place to prevent bruteforcing. Assume they do, though. Are you comfortable assuming the only route an attacker will persue in exploiting this password situation is bruteforcing passwords via a single remote machine?

@AdrianTodorov CSRF tokens don't prevent an attacker from POSTing values to a page on a computer that they control. Its trivial for an attacker to request a page, extract the CSRF token, then use that in their subsequent POST request. Same goes for sessions. In general, nothing you can do client-side is going to stop an attacker from making brute force attempts against a login form. Any protective measures would have to be implemented server-side.

on storage if it's a bank it's very likely they're using an HSM for password storage. Unless they've made heinous mistakes in managing it, compromising the encrypted (yes encrypted not hashed) password wouldn't help you much, so that part of your answer isn't likely correct (or at least you lack sufficient information to reach the conclusion you have reached)

@perfectionist - be aware that your cherry picking of info from Troy Hunt misses some of the key context. See RoryMcCune's comment above, as well as @paj28's answer