Unfortunately it is very common. The approach a lot of companies are taking to telephone agents not knowing user's passwords is to ask for only three letters of them - the agent on the phone needs to type these in to have them verified - and this is not possible if the password is stored after processing with a salted hash.

The reason this is done is that it reduces reply attacks which is a significant concern for over-the-phone authentication. Using the three-characters-from-your-password method someone listening in to your call won't be able to call back and authenticate as you unless they have listened in to enough calls to piece together the whole password.

The usual method is to store the passwords in a strong but symmetric encoding which is no more secure than plain text if an attacker can get both the stored passwords and the key(s). the risk can be mitigated (though not completely removed) by making sure the keys are never stored anywhere near where the passwords are stored, but at some point in the process the key and the encoded password must meet for at least a brief moment.

Essentially this becomes a problem of weighing one risk against another: is the potential loss of security if the account data store is compromised justifiable when considered against the likelihood of successful replay attacks if you must hand over the whole password each time?

One suggestion I've seen is to store (salted and hashed) each combination of three characters without any external indication of which combination each hash represents (so for abcdefghi you would store encodings of 01a02b03c, 01a02b04d, and so on, meaning 720 stored hashes for that ten character password). That way you can check any combination by checking that the resulting hash value exists in the set. This is probably not a good solution though: if an attacker gets hold of the hashes then if they also know the salt they only need 46,656 attempts to derive the content of each hash (assuming a mix of numbers and single case letters is required) so 33.6 million checks would guarantee revealing a 10 character password instead of 3.6 thousand million million - reducing the processing requited by a factor of 100 million. I say "probably not a good solution" as I've done no analysis of this complexity compared to the relative non-safety of passwords stored in a reversible encoding - though I assume the fact I've not seen any such analysis from a trusted source either indicates that it isn't a solution relevant experts feel should be taken seriously.