Hacker News new | ask | show | jobs
by colanderman 4415 days ago
That makes perfect sense. 'A' and 'a' are both on the 2 key, along with 'b', 'c', 'B', and 'C'.
3 comments

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.

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.

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.
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?
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.
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 ;)

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

That, I think, is the correct inference.

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