[jfoster]

If they were OK with applying more duct tape, why not map Q and Z to characters (eg. A and B) that can be part of passwords? (eg. a password of "quiz" would become "auib")

It would make their password system slightly weaker perhaps, since freq(a) then becomes more like freq(a)+freq(q) and freq(b) more like freq(b)+freq(z). I'm not sure that's much weaker than just excluding Q and Z, though. The user experience is improved. The major downside would be in technical debt.

[elwell]

Or you map them to something like:

Q = ABDHCJSKJDHSSS

Z = YYYDUHUHUHSSYS

... to avoid weakening the password.

[napoleond]

I can't tell if you're joking or not, but for the benefit of people who don't know any better: such a scheme would not meaningfully impact the strength of the password storage scheme at all. (To prove it to yourself, think about how rainbow tables work. Then consider how little additional work would be required to replace all Q's and Z's with the appropriate string before making the table. It's not much different from having a "salt" that's the same for every user in your application, which also doesn't meaningfully impact the strength of the password storage scheme.)

[jpatokal]

Actually, it's a classic case of security through obscurity. If the attacker doesn't know about it and are using a standard rainbow table, then no, it's not going to have "ABDHCJSKJDHSSS" in there and it will make their life harder. Once they do find out, though, it's useless.

[georgemcbay]

Or just map them to asterisks, and call it a hunter2 transform...

"Cannot contain special characters or symbols (such as !#$@*, etc)"

Well, damn! Guess that won't work.

[dredmorbius]

At the time the underlying system was designed, Q and Z weren't mapped.

Subsequently they were mapped, but inconsistently across phonesets.

The ITU E 1.161 / ANSI T1.703-1995/1999 / ISO/IEC 9995-8:1994 standard didn't become established until relatively recently. Guessing from the nomnclature, I'd assume subsequent to 1995 / 1999.