[JadeNB]

> This does mean that you need to be able to check subsets of the characters in the password, which rules out hashing the whole password in this case.

As you implicitly point out, however, it doesn't require any portion of the password ever to be visible to the call-centre employee; one can just supplement an individual hash by a collection of hashes of appropriate character subsets, and then (say) randomly pick among the available subsets.

[Vendan]

note though, that this means you have a collection of hashes for the password that are each 3 characters or whatever long, which can be brute forced in essentially no time at all. Crack em all, lay them out according to what letters the hash is for, put it all together and you are done. Even just having 1 subset reduces your passwords security by that many letters, if not more (you can filter out dictionary guesses that don't match those letters and such)

[JadeNB]

Good point. Would salting them obviate the problem?

[Vendan]

nope. Salt is good for eliminating rainbow tables and similar vectors. At this level, let's just say you go after uppercase, lowercase, digits and 20 different symbols, (a total of 82 letters) you'll wind up with 551,368 possible combinations. The only way to make it "safe" would be to get a hash method that would take multiple seconds to run on good hardware. (as a comparison, I crack raw NTLM at something on the order of billions of hashes per second)