"Salting" makes sense only as part of password hashing. From the response you got ("passwords [...] are on a secure, encrypted channel"), one may infer that:
- Passwords are not hashed at all. The bank is able to recover your password at any time.
- Some sort of encryption is applied, either for the storage itself (with an unspecified key) or for the transfer from one machine to another within the bank system (probably SSL). Or maybe both.
- Whoever answered you does not consider that you can understand technology, or does not understand technology himself, or both.
As for the limitation on password length, it is indeed a problem and a very poor practice, since it prevents you from using passwords with high entropy and yet easy to remember (see this question). There may be technical reasons for that (compatibility with a legacy system -- and there are a lot of legacy systems in banks), but it is equally plausible that the limitation comes from a poorly understood Tradition (see this question).
Now let's take the point of view of the bank. What is the use of your password ? Is it to protect the your assets ? No ! The password is there to protect the bank. Not you. Your password is not for you; it is for them.
The bank, as a whole, wants to make money. Successful attacks make them lose money, because:
- they have to refund the user;
- they must deal with the loss of reputation.
Passwords can be used to reduce these losses, in several ways:
- If the break-in is through guessing the password of a user, then the bank can claim that it is not their fault, but the fault of the user who chose a weak password. This limits the damage to reputation.
- Similarly, if they can point the user for being at fault, they may get away with not refunding him.
If the password is strong, then the probability of a breach is lowered. However (and that is an important point), long and complex passwords increase the probability of the user forgetting his password. Such an occurrence implies a phone call to the helpdesk, hence a loss of money. There is a potential for a trade-off here.
What must be remembered is that the bank tries to maximize its own profits and thus uses criteria which do not necessarily match your own assessment of the situation. They may oppose really strong user passwords if such passwords imply higher cost on their part, be it on compatibility layers with legacy systems or increased helpdesk usage. Their best interest does not necessarily match your best interest.
Moreover, password security is poorly implemented in general, because it is not well understood, as is demonstrated by the abundance of myths floating around (e.g. the myth which says that including punctuation signs improves security). That the bank is old does not mean that it is good at handling recent technology.
In any case, most cases of bank account theft are not due to a password too easy to guess, but to a password which was stolen with a key logger. Chances are that the effect of the "password rules" does not even show up statistically, so the bank has no real way to measure how efficient or inefficient that specific security policy is.