4 ms·

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

• acdha 13y ago
  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.
• colanderman 13y ago
  That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b', 'c', 'B', and 'C'.
  • pc86 13y ago
    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 13y ago
      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 13y ago
        But you're making the mistake of assuming they're hashing passwords at all ;) That, I think, is the correct inference.
  • gcb0 13y ago
    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 13y ago
      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 13y ago
        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 13y ago
        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?
  • gcb0 13y ago
    you make too many assumptions. why not A and a instead of a and A? ...the letter on the key is usually the uppercase.
• RobotCaleb 13y ago
  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 13y ago
    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 13y ago
    Definitions of competence vary with time and circumstance. The formerly competent may become the currently incompetent, with no change in skillsets or capabilities.