[dredmorbius]

As several people have noted, the Q/Z restriction likely arises from inputting passwords from a telephone keypad.

What I haven't seen is a statement as to why this would have been a problem. The reason is that Q and Z were mapped inconsistently across various phone keypads. The present convention of PQRS on 7 and WXYZ on 9 wasn't settled on until fairly late in the game, and as noted, the airline reservation system, SABRE, is one of the oldest widely-used public-facing computer systems still in existence, dating to the 1950s.

https://en.wikipedia.org/wiki/Sabre_(computer_system)

The 7/9 standard, by the way comes from the international standard ITU E 1.161, also known as ANSI T1.703-1995/1999 and ISO/IEC 9995-8:1994).

http://www.dialabc.com/words/history.html

Other keypads may not assign Q or Z at all, or assign it to various other numbers, 1 for Australian Classic, 0 for UK Classic and Mobile 1.

http://www.dialabc.com/motion/keypads.html

Similarly, special characters can be entered via numerous mechanisms on phone keyboards.

My suspicion is that there's a contractual requirement somewhere to retain compatibility with an existing infrastructure somewhere.

[breadbox]

And as others have noted, this doesn't make sense given that passwords are case-sensitive and are required to include uppercase characters.

If there's a mechanism for specifying case on the phone, there can be a mechanism for specifying Q and Z unambiguously. I certainly have used VM systems that explicitly told me to "use 7 to represent Q and 9 to represent Z."

A contractual requirement is one possibility that could explain it, but my suspicion is rather that some legacy code in the system uses Q and Z as special escape characters or delimiters (because of their absence on the phone dial), and it's not worth the cost to try to fix the ancient code (or do all the testing necessary to be confident of deploying a workaround).

[dredmorbius]

Case-sensitivity is an interesting observation. It makes it 1) more likely that the passwords are being stored and that 2) there are multiple interfaces used: the Web front-end which can handle capitalization (something which can be unambiguously transformed) and a back-end SABRE system which likely cannot but a case-shifted password could still be passed to it.

As for your voicemail system, that merely gets around the issue of competing standards by enforcing its own. And the mapping has to be repeated to every user for every use of the system. I'd actually consider it an argument in favor of the keypad theory.

Escape codes (or testing codes) is another possible explanation. And legacy code cost is indeed often a consideration.

[gcb0]

so, they have a requirement to maintain compatibility with telephone password input, but require an uppercase character as well? it does not make any sense.

this is incompetent developers in a dysfunctional environment. there is no good light anyone can throw at it. and no, having the system live since the 50s is not a good excuse. it is certainly not the same system, for obvious reason.

[colanderman]

That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b', 'c', 'B', and 'C'.

[gcb0]

Wait. are you saying that phones that didn't even have the Q and Z inputs are capable of uppercase and lowercase?!

all my really old nokias and ericsson and motorolas (that did have Q and Z :) did not made uppercase... pressing one key over and over would cycle the lower case chars only.

[colanderman]

We're not talking about text messages; we're talking about DTMF tones. You push the button once, the remote end receives that digit (say, "2"), not a character.

Hence, the remote end must assume the "2" to represent either an "A", "B", or "C". What I'm saying is that it's reasonable to further assume that, if the user pressed "2", they may have pressed it to indicate one of the three corresponding lowercase characters. Humans generally ignore case.

What's not reasonable is to assume that a human, faced with a DTMF pad without a Q or a Z, would press anything. Sure, you could interpret all digits as a possible "Q" or "Z", but it's equally likely that a human in such a situation would leave the character out, or give up and call tech support. It's simpler to just disallow these characters.

[dredmorbius]

Assuming the system is capable of being accessed both by phone and by a fully-keyboarded device (including, I suppose, a fully-keyboarded phone), then you've got the challenge of authenticating based on either the DTMF tones or the keyboard input. Which means you'd either have to record the hashes both forms (and figure out how to supply the keyboard variant if the initial input is a phone, or allow all compatible keyboard variants), or you're storing the password and comparing the input directly.

[gcb0]

but thats my point. if that password rule were to support phones, which i doubt, why the other rule demands a lower case and an upper case char?

[pc86]

Does this mean that passwords entered on the phone are hashed/encrypted in a case-insensitive manner? I don't understand how this can work unless you're doing the equivalent of .ToLower()/.ToUpper() on everyone on the back end.

[colanderman]

Not just case-insensitive, but character-group-agnostic. All the backend knows is that the user pressed "2"; it doesn't know whether that "2" means "A", "B", or "C". (Or, to my point, "a", "b", or "c".)

But you're making the mistake of assuming they're hashing passwords at all ;)

[dredmorbius]

But you're making the mistake of assuming they're hashing passwords at all ;)

That, I think, is the correct inference.

[gcb0]

you make too many assumptions. why not A and a instead of a and A? ...the letter on the key is usually the uppercase.

[acdha]

Consider how important air travel is and the wide range of situations people use to book or change travel plans. It's completely unsurprising that someone would be reluctant to say that no device or system in use anywhere in the world would have a problem with this.

[RobotCaleb]

How far we've come that incompetent only means "enforces strange password rules" while still putting out a large, complex (and functional!) system instead of, well, incompetent.

[brokentone]

Password rules is one place that is relatively visible that shows business rules and tech limitations in play.

If the system shows a misunderstanding of security or makes it clear that shortcuts were taken, then what is to make you think the same didn't occur on a deeper and more important level (databases, security, etc).

[dredmorbius]

Definitions of competence vary with time and circumstance. The formerly competent may become the currently incompetent, with no change in skillsets or capabilities.

[rjbwork]

A lot of the comments under this top level one are a bit absurd in decrying that this means they aren't doing anything right and have a bunch of devs in bad environments.

It's as simple as:

1) On password change/account create, run through a small algorithm that turns the password into a series of digits that represent the password as if it were entered on a phone.

2) Hash both password and "digitized" password into 2 separate fields in your store.

3) Now support phone inputs for passwords.

[eli]

You don't see how it might have been a problem for the original system to allow you to set a password on one phone that (appears to be) impossible to enter on a different phone?

[dredmorbius]

That's specifically the problem that the Q/Z restriction works around.

[krunk4ever]

I've encountered telephone login systems which ask me to type in my password in its numeric form (e.g. if my password was 'password', I'd type 72779673)

If JetBlue has a similar logic system via the phone, I can see why Q and Z or prohibited to allow this existing authentication system to work.