This is a bad, bad policy. There are only 106 or a million different 6-digit numbers. That is so too little.
It is almost impossible to prevent an offline brute force attack, no matter how slow a hashing algorithm you use. If one attempt takes 1 second, you will crack a password in 11 days. It may also be too little to completely stop a clever online brute force attack, if the attacker can use multiple IPs (say, from controlling a botnet) and has many different card numbers to try on.
This is made worse by the fact that, just like with ordinary passwords, most people don't pick them at random.
123456 is bound to show up a lot, and so are numbers that represent dates. In practice, most passwords will have much less than 6×log2(10) ≈ 20 bits of entropy.
I can see no reasons why you should not be allowed to pick a stronger password. This practice sends the signal that they simply do not care about security. It also makes me suspect that somewhere in their database there is a
NUMBER(6) instead of a hash stored.
That payments can't be done without another factor of authentication is a bit comforting, but not much. An attacker could still see your account history, something that could contain very sensitive information and also be used for phishing.
Even if this will probably never be used against you, if I were you, I would consider switching to a new bank. Preferably one that requires two-factor authentication at login.
There has been some discussion in comments and some good answers with another view has popped up, so I would like to elaborate and respond to some critiques.
But the usernames are secret!
According to the question, the ID card numbers (not to be confused with credit card numbers) are "almost public", and OP has clarified in comments that he has seen lists of them as "results for public sector services". In other words, the usernames are not secret. And they should not have to be – if the security of your system rests on the fact that the usernames are secret, you are doing it wrong.
Rate limit per account and/or IP number will take care of this.
A distributed brute force attack, e.g., using a botnet, would have a decent chance to break a few accounts. Let's say you have 10 000 computers, and each computer tests 3 passwords per day during a month on different accounts. That is about 106 attempts. That will give you one account on average if the passwords are truly random. In the real world, you will get much, much more.
Sure, the bank could theoretically have some sophisticated system to detect and defend against attacks like this. Maybe, maybe not. As a customer, I have no way of knowing, and I certainly do not trust an organisation that can't even get the password policy right to do anything more advanced.
An offline attack is irrelevant. If the passwords are out, so are the sensitive data they are protecting.
Maybe, maybe not. There are plenty of data dumps floating around the Internet with incomplete data. To claim that the passwords will be forever glued to your account history makes some very strong assumptions on how the breach happened and how the data was handled afterwards.
Your credit card PIN is only four digits, so what does it matter anyway?
Your credit card PIN is one weak factor in a two-factor authentication. The other factor – possession of the card – makes the system stronger.
This password is a weak factor, and it is also the only factor protecting your financial information.
To be clear, I am not saying it would be impossible for a bank to make this system secure with other means. I am not saying a successful attack on anyone's account is likely, even less so on yours specifically. What I am saying is that this is not "secure enough" for a bank.
The bank has already gone through the trouble of setting up two-factor authentication for financial transfers. Why not just use it for logins as well?
The bank has (hopefully) already gone through the trouble of hashing a password and storing it in a database. Why not just remove the part of the code that limits the password to six digits?