[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.