If the description of password+number is accurate, then it's a poor solution because it means your password is sent to the bank as opposed to being hashed and the hash being sent to the bank.
This comes up every time passwords are discussed, and it's a bad idea. A password sent over a secure channel is fine. A hashed password sent over a secure channel is generally fine, though more complicated. A password sent over an unsecured channel is not fine. Neither is a hashed password sent over an unsecured channel.
Hashing the password before transmission gains you basically nothing. Hashing on the client side simply means that your hashed password becomes the effective password. Anyone who could theoretically sniff the password could also sniff the hashed password and perform the same kind of impersonation or man-in-the-middle attacks. You're introducing a bunch of complexity (and breaking compatibility with clients that don't, e.g., support Javascript), and you're getting nothing useful in return. And yes, you could implement some kind of challenge-response and basically try to reimplement a secure handshake and auth, but you'll probably get it wrong because security implementations by laypeople are generally quite broken, and at the end of the day, you should just turn on SSL and do it the way that works.
This is common practice. Our password forms all over the internet send the password just as part of a normal request. We rely on SSL to protect that data as it goes over the wire and then there are all sorts of ways that it might be stored in plain text somewhere on the servers.
They could just, in RAM, take off the last 6 characters of the password they got and treat those as the token with the rest being the password itself. At this point it's not much different from passing them separately.
The main point of the original rant was that we have a solution that doesn't require this, but it's not used for any websites.
